On Fri, Nov 19, 2010 at 02:15:54PM +0100, torbenh wrote:
On Wed, Nov 17, 2010 at 03:16:32PM +0800, Raymond Yau wrote:
2010/11/12 Paul Menzel paulepanter@users.sourceforge.net
Am Mittwoch, den 10.11.2010, 11:18 +0100 schrieb torbenh:
On Mon, Nov 08, 2010 at 10:26:47AM +0100, torbenh wrote:
the alsa jack plugin has quite some problems: a) does not work correctly with mplayers alsa output. (and quite a few others)
AFAIK, mplayer , aplay and the alsa-jack plugin 1.0.1still working with jack-0.118
So you have to tell the jack plugin fail to work from from which version of jack if jack change the protocol
jack did not change the protocoll.
however, the write to the socket fd might block. doing potentially blocking things in jacks process callback is not legal. (this kind of problems only show under low-latency situations, period_size of 128 and lower)
the result of the blocking write is jack kicking the client. and just making the fd NONBLOCK, "fixed" the problem. (it seems to cause some other problems down the road, since some bytes written to the fd get lost)
i would really like to exchange the socket for a signalfd. increasing the signal count of the fd would never block.
err... that should read eventfd, obviously :S
(but i am not sure about the requirements, signalfd only exists since 2.6.27, and i am not sure, if the old socket based code should be left in there as a fallback)
The current Documentation of jack plugin "doc/README-jack" has a mistake
pcm.jack { type jack playback_ports { 0 alsa_pcm:playback_1
1 alsa_pcm:playback_1
1 alsa_pcm:playback_2 } capture_ports { 0 alsa_pcm:capture_1
1 alsa_pcm:pcapture_1
1 alsa_pcm:pcapture_2 } }
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
-- torben Hohn _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel