At Fri, 04 Sep 2009 11:09:17 +0200, Halim Sahin wrote:
On Fr, Sep 04 2009, Takashi Iwai wrote:
At Wed, 02 Sep 2009 10:56:17 +0200, Halim Sahin wrote:
On Di, Sep 01 2009, Takashi Iwai wrote:
At best, we need a small C code that reproduces the behavior.
Ok here is a small example. It's a modified version of pcm_min.c. Simply press ctrl+c to reproduce the problematic behaviour. on my machine it takes about an half sek to stop with an usb head which uses dmix.
Hmm, I cannot reproduce the problem, at least, dmix + HD-audio. After removing sleep(1), it quits immediately.
Yes you can't, because the program doesn't run. The sleep shouldn't be removed to see the problem.
I don't understand here. So, how is the problem exactly? In which point is the delay expected and where not expected?
You catch a signal and add a delay there -- so the program works, no? If you are checking whether snd_pcm_drop() is executed immediately or not, you should put a printf() after snd_pcm_drop() to indicate when the function call finishes.
When speech-dispatcher is running and someone tries to stop the output, the programm doesn't exit.
So, "doesn't exit" is the intended behavior?
Think about it like a pause key :-).
The sblive stopps emmidiately with inserted sleep the usb headset doesn't.
In that sense, HD-audio + dmix works as well. There is no 0.5 sec delay in snd_pcm_drop() itself but the code to sleep immediately.
Doesn't this problem happen if you use usb-audio with "hw" PCM?
The pcm_min example of alsalib doesn't run this way. --8<---------------cut here---------------start------------->8---
ALSA lib pcm.c:7125:(snd_pcm_set_params) Sample format not available for PLAYBAC K: Invalid argument Playback open error: Invalid argument --8<---------------cut here---------------end--------------->8---
Can you tell me which sampleformat works with this device???
Use plughw instead.
It's possible that the behavior of snd_pcm_drop() of usb-audio is different from others because of URB handling.
The stop problem also happends on my laptop with hd audio and ad1981 chip.
Works fine on my machine. There shouldn't be any difference with the codec chip regarding this, and very unlikely due to the difference of controller chip, too. So, the hardware shouldn't be a problem as long as you use the relatively new version of alsa-driver.
The question might be the alsa-lib version. I've tested only with the latest one, alsa-lib-1.0.21.
Takashi