# 48khz sound stuttering/performance



## Yelphos (May 16, 2018)

I always recognised some very hard stuttering within some games using wine and I found out this is caused by the sound-implementation of FreeBSD.

To be specific:

48khz sample rate means no stuttering within grim dawn for e.x.
192khz sample rate means very hard stuttering within grim dawn for e.x.

I wasn't able to test this on all games yet but I assume it's a lot more games or even all games being affected by it.

PR 228298

This thread is opened to inform about this issue.


----------



## zirias@ (May 16, 2018)

This really isn't a proper PR.


----------



## SirDice (May 16, 2018)

I agree. As it stands it's likely going to be ignored or closed.


----------



## shkhln (May 16, 2018)

Yelphos said:


> 48khz sample rate means no stuttering within grim dawn for e.x.
> 192khz sample rate means very hard stuttering within grim dawn for e.x.



Mixing is done on the CPU, 192 kHz is obviously 4 times (192 / 48 = 4) more resource intensive than 48 kHz.


----------



## Yelphos (May 16, 2018)

Changing kernel-behaviour to always choose the last cpu/thread for soundprocessing should solve this.

It's hard to believe to me that soundprocessing is causing that much impact on performance.


----------



## shkhln (May 16, 2018)

First, quotations should be formatted accordingly and the source explicitly stated, in this instance https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228298#c1. Second, I don't believe that comment disagrees with me. Third, it's your responsibility to measure the performance impact.


----------



## zirias@ (May 16, 2018)

Well with *that* comment, I'm sure everything is settled and someone will fix the kernel </sarcasm>


----------



## shkhln (May 16, 2018)

shkhln said:


> First, quotations should be formatted accordingly and the source explicitly stated, in this instance https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228298#c1.



Ah, so that's your own comment... Anyway, what's your suspected cause of the issue?


----------



## Adrien2002 (Dec 10, 2019)

I use this thread instead of making a new one to say that the "stuttering" audio is only when you set Wine to Windows 7 and above. No problem when set to Windows XP. No problem... Until recently. Steam can not be used anymore with Windows XP so every Steam games now have stuttering sound which is mh... Not so cool :/ Uplay can't be used with Windows XP either so all my Ubisoft games have the sound issue.

I say stuttering but it's more cracking sound than stuttering and not every sound in the game is cracking. When I play Far Cry 3, for example, the gun sound isn't cracking but, driving a car is hell 

I tried to play with "hw.snd.latency", "hw.snd.latency_profile" and "dev.pcm.0.play.vchanrate" as suggested in the PR posted on top of this thread but it changes nothing. I want to be clear on a point : ONLY Wine has this problem. native video games, mpv, moc, Firefox etc etc etc... They all are perfectly working. Only Wine and only when set to Win7 and higher

Maybe Wine team didn't spend enough time working on sound for OSS, as suggested in the PR ? But I doubt they still offer support for it. It's already a miracle if you get support for FreeBSD so, for an old as sh*t sound system... No chance.


----------



## sidetone (Dec 10, 2019)

Either your sysctl settings for OSS were too high or improper, or a Linux implementation which includes bloat, like including Alsa (and dependencies which bring in more dependencies unrelated to sound) contributed to it. OSS is very efficient, so it's very unlikely to be inherently that.

Wine could be made better, as having an /etc directory under a /compat directory. Also, by having an i386 base or maybe chroot, with all emulators that need 32bit working under it. Even having executables secured from the rest of those files. But it's upstream, so they won't do that, plus they may not understand the importances.

There's also that for Windows software is a completely different system, with programs not intended for use on opensource platforms, and it's a wonder when something does make it work.

I had a problem with OSS once, but then I changed or removed settings pertaining to it in sysctl.conf or boot.conf, and that fixed that.


----------



## shkhln (Dec 10, 2019)

Adrien2002 said:


> I use this thread instead of making a new one



Please don't, it's a bad habit to get into.



Adrien2002 said:


> to say that the "stuttering" audio is only when you set Wine to Windows 7 and above.



That sounds improbable.


----------



## Adrien2002 (Dec 10, 2019)

sidetone said:


> Either your sysctl settings for OSS were too high or improper, or a Linux implementation which includes bloat, like including Alsa (and dependencies which bring in more dependencies unrelated to sound) contributed to it. OSS is very efficient, so it's very unlikely to be inherently that.
> 
> Wine could be made better, as having an /etc directory under a /compat directory. Also, by having an i386 base or maybe chroot, with all emulators that need 32bit working under it. Even having executables secured from the rest of those files. But it's upstream, so they won't do that, plus they may not understand the importances.
> 
> ...



I didn't make any changes in sysctl. I mean I tested by changing things on the fly using "sysctl -w" but after a reboot, none of my changes remain and I'm still having this cracky noise with the audio. My sysctl.conf is still the original one, with commented stuff in it.



shkhln said:


> That sounds improbable.



Yes, it seems I was wrong about this. Mh... After some tries, the cracky audio happens when the game doesn't run well enough (WinXP included). The thing is that the sound is slowed down. Musics can become slower, voices too, like when you do emulation of a gaming console and you don't run the game at full speed but instead of normal slowed down audio (or jumpy slowed down audio), the audio is slowed down and cracking which is unpleasant to listen.

And the difference with my example of gaming console emulation above is that the game, under Wine, still runs at full speed (with stuttering image, absolutely normal behavior when your computer isn't beefy enough) SO when two people are speaking, one might start before the other finished his last sentence because his speech was slower than expected. It only happens when the game is slowed down because of hardware (or maybe driver) limitation. When the game runs smoothly, the audio is perfect.

Now this is not normal, is it ?

dev.pcm.0.play.vchanformat: s16le:2.0
dev.pcm.0.play.vchanrate: 48000
dev.pcm.0.play.vchanmode: passthrough
dev.pcm.0.play.vchans: 1
hw.snd.latency_profile: 1
hw.snd.latency: 2

These are default settings I have in sysctl. I tried lower the vchanrate and increase it, change the value of latency and latency_profile but no expected result. I really don't know if it's only related to Wine or if it is system-wide. I'll install Xonotic and run it at max settings. If I'm not mistaken, I might have a bit of troubles running it in ultra. If the sound remains correct on Xonotic, it might help to diagnose the problem ?

Oh and by the way, should I simply let this thread and make a new one ?


----------



## sidetone (Dec 10, 2019)

Adrien2002 said:


> I didn't make any changes in sysctl. I mean I tested by changing things on the fly using "sysctl -w" but after a reboot, none of my changes remain and I'm still having this cracky noise with the audio. My sysctl.conf is still the original one, with commented stuff in it.





> Now this is not normal, is it ?
> 
> dev.pcm.0.play.vchanformat: s16le:2.0
> dev.pcm.0.play.vchanrate: 48000
> ...


Comment those out, and try again. When I had settings there, it made mine act like that for the whole system. Default doesn't have those set. That's probably your problem, if it were, it's as I mentioned. Comment them out, and reload it before insisting there's a bug.

Then again, when my sound worked properly, it didn't work well for an emulator I used. If this is the case, it's because of bloat and/or a hard time trying to match the emulated software.

Whatever it is, OSS isn't the problem. The sound architectures which aren't of FreeBSD which output to OSS could be the problem.


----------



## Adrien2002 (Dec 10, 2019)

There are no line in my sysctl.conf but I did as you asked. I added the lines and commented them out. The problem is still the same (and the settings are still identical to what they were before touching sysctl.conf).

I tried to take a video pf my problem with my phone. The quality isn't very great but you can hear (and see) the two problems I'm having : 



_View: https://www.youtube.com/watch?v=f5rhg-PwFeU_


You can see the first few words are synced to mouth of the character because they are loaded at the same time as the movements of the character but the audio is not as "fast" as the character movements, make the lipsync asynced quickly. Then, the other guy's time to talk comes at the right time and will start to speak on top of the first one unfinished sentence. It's an abnormal behavior, I played the game for years (it's my favorite Assassin's Creed) and this problem shouldn't exist.

The second problem, that cracking noise can be heard especially at the end of the video when I use that blue vision where everything glows blue. Assassin's Creed isn't that affected because, globally, the game runs not bad on my hardware.

Far Cry 3 is more cracky than Assassin's Creed : 



_View: https://www.youtube.com/watch?v=JkOXvy_42jc_

I invite you to listen to the original Far Cry 3 theme which is right here : 



_View: https://youtu.be/rfAeL4JfHj8?t=10_

The speed difference is noticable.


----------

