Raymond Yau wrote:
How about the qualtity of the playback ? did you speak to the mic and hear the result ?
Yes, when speaking into the mike I can hear the output on the speakers. The sound quality is reasonable for 8kHz S16_LE and there are no sound errors (e.g. no clicks or similar).
Refer to your pulseaudio log , PA use "front" device for playback/capture
I: module-alsa-sink.c: Successfully opened device hw:0. I: alsa-util.c: Successfully attached to mixer 'hw:0' I: alsa-util.c: Using mixer control "PCM".
Here you can see that PA uses the "hw" device. (It just tries to use the "front" device in the beginning which fails. The "hw" device is opened successfully after that (see log above).)
but your test use "hw"
In my tests I first used the "default" device which uses the PA plugin. The test clearly showed that poll() returns with POLLIN even though far less than avail_min frames are available for reading. Hence I suspect that there is a *bug* somewhere in the pulseaudio code (either the plugin or the daemon).
In order to show that my code is working fine and the erroneous poll behavior does not occur when PA is not used, I also tested with the "hw" device. The result, as mentioned, it that the POLLIN event is correctly returned after at least avail_min frames are available.
In short:
* test with "default" uses PA: erroneus poll() behavior, BUG * test with "hw" does *not* use PA: everything works fine
Do you mean that you suspect the problem is related to alsa-pulse plugin or PA server ?
Yes.
cheers, Stefan