Hi.
I've noticed the winealsa does not handle alsa XRUNs. In the case of XRUN application hangs.
That's happened because return value of snd_pcm_avail_update() is not checked.
For example: wavein.c 175 DWORD bytes; 180 /* read all the fragments accumulated so far */ 181 frames = snd_pcm_avail_update(wwi->pcm); 182 bytes = snd_pcm_frames_to_bytes(wwi->pcm, frames);
waveout.c 476 DWORD availInQ; 479 availInQ = snd_pcm_avail_update(wwo->pcm); 482 if (availInQ > 0) {
The snd_pcm_avail_update() returns a _signed_ type and it really does return negative number -EPIPE in the case of XRUN.
More over, any return value of less than period_size may indicate XRUN state too. The snd_pcm_state() may help then.
Th dsoutput.c and dscapture.c do exactly the same wrong thigs.
BTW, using DWORD type causes problems. Following fragment is from wavein.c too:
177 DWORD read; 181 frames = snd_pcm_avail_update(wwi->pcm); 182 bytes = snd_pcm_frames_to_bytes(wwi->pcm, frames); 193 read = wwi->read(wwi->pcm, lpWaveHdr->lpData + 194 bytesRead = snd_pcm_frames_to_bytes(wwi->pcm, 197 if (bytesRead != (DWORD) -1)
This is obviously will not work as expected.
I hope someone will fix these issues :)
Regards, Tim.
Hello Timofei,
Timofei V. Bondarenko schreef:
I've noticed the winealsa does not handle alsa XRUNs. In the case of XRUN application hangs.
I'm aware of the xrun problems in alsa at least the accelerated parts (dsoutput/dscapture), it's been on my todo list for a while but I've been busy lately. The problems with the accelerated parts are not the underruns themselves. They are handled correctly in the places where it matters. The problem is how the underruns are handled in the directsound software mixer. I haven't taken a look yet at how underruns are handled for the not-accelerated system, but I believe that the chance of a underrun there is already very low because buffers there usually have a latency of at least 300ms.
Regards, Maarten.
Maarten Lankhorst wrote:
Hello Timofei,
Timofei V. Bondarenko schreef:
I've noticed the winealsa does not handle alsa XRUNs. In the case of XRUN application hangs.
I'm aware of the xrun problems in alsa at least the accelerated parts (dsoutput/dscapture), it's been on my todo list for a while but I've been busy lately. The problems with the accelerated parts are not the underruns themselves. They are handled correctly in the places where it matters. The problem is how the underruns are handled in the directsound software mixer. I haven't taken a look yet at how underruns are handled for the not-accelerated system, but I believe that the chance of a underrun there is already very low because buffers there usually have a latency of at least 300ms.
No matter how low the chance: sound is an real-time task while linux is not a real-time system. So underruns still possible. And in case of XRUN widRecorder() tries to read about 4G of data.
Well, I'm a busy man too. So I've wrote a simple patch and sent it to wine-patches. Please look. May be it will be more clear in C than in my broken english.
Regards, Tim.
Hello Timofei,
Timofei V. Bondarenko schreef:
No matter how low the chance: sound is an real-time task while linux is not a real-time system. So underruns still possible. And in case of XRUN widRecorder() tries to read about 4G of data.
Well, I'm a busy man too. So I've wrote a simple patch and sent it to wine-patches. Please look. May be it will be more clear in C than in my broken english.
I took a quick look, it's incorrect for dscapture and dsoutput, underruns are already handled there in CheckXRUN, in case of _Stop it is unneeded as well since it just stopped and restarted, no underruns possible. The only thing needed in that part is that the < 0 checks need to have a cast to sframes.
Regards, Maarten.
Maarten Lankhorst wrote:
Hello Timofei,
Timofei V. Bondarenko schreef:
No matter how low the chance: sound is an real-time task while linux is not a real-time system. So underruns still possible. And in case of XRUN widRecorder() tries to read about 4G of data.
Well, I'm a busy man too. So I've wrote a simple patch and sent it to wine-patches. Please look. May be it will be more clear in C than in my broken english.
I took a quick look, it's incorrect for dscapture and dsoutput, underruns are already handled there in CheckXRUN, in case of _Stop it is unneeded as well since it just stopped and restarted, no underruns possible. The only thing needed in that part is that the < 0 checks need to have a cast to sframes.
Sure, you know better about it supposed to work ;-) when i can notice the obvious mistakes only.
My main concern is the widRecorder() not the ds though.
Regards, Tim.
Hello Timofei,
Timofei V. Bondarenko schreef:
No matter how low the chance: sound is an real-time task while linux is not a real-time system. So underruns still possible. And in case of XRUN widRecorder() tries to read about 4G of data.
Well, I'm a busy man too. So I've wrote a simple patch and sent it to wine-patches. Please look. May be it will be more clear in C than in my broken english.
I took a quick look, it's incorrect for dscapture and dsoutput, underruns are already handled there in CheckXRUN, in case of _Stop it is unneeded as well since it just stopped and restarted, no underruns possible. The only thing needed in that part is that the < 0 checks need to have a cast to sframes.
Regards, Maarten.
-
Maarten Lankhorst -
Maarten Lankhorst -
Timofei V. Bondarenko