Hi,
Maarten Lankhorst wrote:
Actually in winepulse, sleep / 12000 (8 ms I guess?) ms would work, no sleep at all works too,
Yes, I wanted to go no further than 8ms below the 10ms period limit.
it was just the mixing of various levels of sleep that was failing. Not sure why though, might be something about the scheduling throwing it off.
There's a perfectly simple explanation of this that applies to both winepulse and winecoreaudio. It goes as follows.
IOW, there's a bug in winecoreaudio. It may explain why the test stutters on my MacOS 10.5.8 machine, regardless of how accurate or "improved" GetPosition is.
winecoreaudio's IAC_ReleaseBuffer sends packets off as soon as it receives data, unlike winealsa/wineoss.
Consider the sleep sequence 0 5 8 0 5 ms...
+ The transition 8 -> 0ms sleep is fine, as data is sent 2ms after the prior packet
- The transition 0 -> 5 is most problematic, as it means that 2 ReleaseBuffer will be 15ms apart, even though only 10ms of data was sent.
I believe winepulse is affected by this too, like winecoreaudio.
The stable sequences "always 0" or "always 8ms sleep" are paced regularly, so underruns are avoided as long as the OS schedules the threads soon enough.
Winealsa and wineOSS are not affected, as they write data on the 10ms period boundaries, -- like native presumably does.
winecoreaudio solution paths: - write packets on period tick, not at release time - or add silence lead-in - or delay first packet until period tick only (if small) - or ...
I think it should be possible to produce reliable continuous sound in winepulse and winecoreaudio yet maintain their current "send packet" codebase instead of transitioning to a separate buffer that winealsa and wineoss use.
Regards, Jörg Höhle
Op 04-12-12 14:28, Joerg-Cyril.Hoehle@t-systems.com schreef:
Hi,
Maarten Lankhorst wrote:
Actually in winepulse, sleep / 12000 (8 ms I guess?) ms would work, no sleep at all works too,
Yes, I wanted to go no further than 8ms below the 10ms period limit.
it was just the mixing of various levels of sleep that was failing. Not sure why though, might be something about the scheduling throwing it off.
There's a perfectly simple explanation of this that applies to both winepulse and winecoreaudio. It goes as follows.
IOW, there's a bug in winecoreaudio. It may explain why the test stutters on my MacOS 10.5.8 machine, regardless of how accurate or "improved" GetPosition is.
winecoreaudio's IAC_ReleaseBuffer sends packets off as soon as it receives data, unlike winealsa/wineoss.
Consider the sleep sequence 0 5 8 0 5 ms...
- The transition 8 -> 0ms sleep is fine, as data is sent 2ms after the prior packet
- The transition 0 -> 5 is most problematic, as it means that 2 ReleaseBuffer will be 15ms apart, even though only 10ms of data was sent.
I believe winepulse is affected by this too, like winecoreaudio.
The stable sequences "always 0" or "always 8ms sleep" are paced regularly, so underruns are avoided as long as the OS schedules the threads soon enough.
Winealsa and wineOSS are not affected, as they write data on the 10ms period boundaries, -- like native presumably does.
winecoreaudio solution paths:
- write packets on period tick, not at release time
- or add silence lead-in
- or delay first packet until period tick only (if small)
- or ...
I think it should be possible to produce reliable continuous sound in winepulse and winecoreaudio yet maintain their current "send packet" codebase instead of transitioning to a separate buffer that winealsa and wineoss use.
Actually, Arun Raghavan found this thread and pointed me towards updating pulseaudio, it seems it was a bug in pulseaudio fixed in 3.0:
Op 20-12-12 12:43, Arun Raghavan schreef:
Hi Maarten, While following some random thread, I cam across this:
http://www.winehq.org/pipermail/wine-devel/2012-December/098008.html
I see you mention:
""" I may also be hitting some pulseaudio bug though, if I play some music on the background when one of those tests start the sound during the test works ok, even if I pause it after that. """
We recently fixed a bug where pausing and resuming a stream could end up adding a hidden latency to the stream, and this would not happen if another stream was playing. The fix is in 3.0, so if this is what you were referring to, might be worth trying with newer PA.
This does make my life a lot easier though, as finding a way to only queue on multiple of periods was giving me a headache, results from 10 seconds now:
render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -881 frames at 44100 worth 9990ms in 9983ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -882 frames at 44100 worth 9990ms in 9990ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -882 frames at 44100 worth 9990ms in 9988ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -881 frames at 44100 worth 9990ms in 9987ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -682 frames at 44100 worth 9995ms in 9986ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -724 frames at 44100 worth 9994ms in 9987ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -881 frames at 44100 worth 9990ms in 9984ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -767 frames at 44100 worth 9993ms in 9989ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -441 frames at 44100 worth 10000ms in 9991ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -882 frames at 44100 worth 9990ms in 9988ms render: 41019 tests executed (0 marked as todo, 0 failures), 0 skipped.
I would be interested in the exact commit though, so I can get it backported to precise/quantal, from ubuntuforums' winepulse thread it seems I'm not the only one that might have been hitting this problem.
~Maarten
On Thu, 2012-12-20 at 13:34 +0100, Maarten Lankhorst wrote:
Op 04-12-12 14:28, Joerg-Cyril.Hoehle@t-systems.com schreef:
Hi,
Maarten Lankhorst wrote:
Actually in winepulse, sleep / 12000 (8 ms I guess?) ms would work, no sleep at all works too,
Yes, I wanted to go no further than 8ms below the 10ms period limit.
it was just the mixing of various levels of sleep that was failing. Not sure why though, might be something about the scheduling throwing it off.
There's a perfectly simple explanation of this that applies to both winepulse and winecoreaudio. It goes as follows.
IOW, there's a bug in winecoreaudio. It may explain why the test stutters on my MacOS 10.5.8 machine, regardless of how accurate or "improved" GetPosition is.
winecoreaudio's IAC_ReleaseBuffer sends packets off as soon as it receives data, unlike winealsa/wineoss.
Consider the sleep sequence 0 5 8 0 5 ms...
- The transition 8 -> 0ms sleep is fine, as data is sent 2ms after the prior packet
- The transition 0 -> 5 is most problematic, as it means that 2 ReleaseBuffer will be 15ms apart, even though only 10ms of data was sent.
I believe winepulse is affected by this too, like winecoreaudio.
The stable sequences "always 0" or "always 8ms sleep" are paced regularly, so underruns are avoided as long as the OS schedules the threads soon enough.
Winealsa and wineOSS are not affected, as they write data on the 10ms period boundaries, -- like native presumably does.
winecoreaudio solution paths:
- write packets on period tick, not at release time
- or add silence lead-in
- or delay first packet until period tick only (if small)
- or ...
I think it should be possible to produce reliable continuous sound in winepulse and winecoreaudio yet maintain their current "send packet" codebase instead of transitioning to a separate buffer that winealsa and wineoss use.
Actually, Arun Raghavan found this thread and pointed me towards updating pulseaudio, it seems it was a bug in pulseaudio fixed in 3.0:
Op 20-12-12 12:43, Arun Raghavan schreef:
Hi Maarten, While following some random thread, I cam across this:
http://www.winehq.org/pipermail/wine-devel/2012-December/098008.html
I see you mention:
""" I may also be hitting some pulseaudio bug though, if I play some music on the background when one of those tests start the sound during the test works ok, even if I pause it after that. """
We recently fixed a bug where pausing and resuming a stream could end up adding a hidden latency to the stream, and this would not happen if another stream was playing. The fix is in 3.0, so if this is what you were referring to, might be worth trying with newer PA.
This does make my life a lot easier though, as finding a way to only queue on multiple of periods was giving me a headache, results from 10 seconds now:
That's good to hear.
render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -881 frames at 44100 worth 9990ms in 9983ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -882 frames at 44100 worth 9990ms in 9990ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -882 frames at 44100 worth 9990ms in 9988ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -881 frames at 44100 worth 9990ms in 9987ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -682 frames at 44100 worth 9995ms in 9986ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -724 frames at 44100 worth 9994ms in 9987ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -881 frames at 44100 worth 9990ms in 9984ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -767 frames at 44100 worth 9993ms in 9989ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -441 frames at 44100 worth 10000ms in 9991ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -882 frames at 44100 worth 9990ms in 9988ms render: 41019 tests executed (0 marked as todo, 0 failures), 0 skipped.
I would be interested in the exact commit though, so I can get it backported to precise/quantal, from ubuntuforums' winepulse thread it seems I'm not the only one that might have been hitting this problem.
The bug becomes really visible when your stream requests a high latency (and no other stream with a lower latency request is connected, like the music player or Flash). This is the commit of interest to you:
http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=29f064aa3d3a83e...
Cheers, Arun
-
Arun Raghavan -
Joerg-Cyril.Hoehle＠t-systems.com -
Maarten Lankhorst