[alsa-devel] Broken JACK plugin in alsa-plugins and a way to fix it.
Hi.
I want to note that JACK plugin in alsa-plugins in broken. (At least on my two systems.) It just plays for a few seconds and then stops hanging the application that was sending data to it. When it hangs jackd spits out this:
subgraph starting at alsa-jack.jackP.3635.0 timed out (subgraph_wait_fd=7, status = 0, state = Running)
What I want to note is that there is a fix to that and I would like it to be included in the tree. I'm not sure if it doesn't break anything else, but it works for me ok.
Open pcm_jack.c and on the line 146 you'll find:
write(jack->fd, buf, 1); /* for polling */
Deleting this seems to get rid of the problem. So please if you can patch this out. (I didn't make a patch myself since this is so tiny fix that it isn't really worth.)
Cheers.
Sorry, it seems that while that fixed the problem for some apps (notably mplayer) it broke a few others. (amarok, artsd) So please just ignore my remake about the fix for now. It would be nice if someone could explain to me why that bug happens, because currently I'm more and more confused about that.
On 5/19/07, Jasiu kiputnik@gmail.com wrote:
Hi.
I want to note that JACK plugin in alsa-plugins in broken. (At least on my two systems.) It just plays for a few seconds and then stops hanging the application that was sending data to it. When it hangs jackd spits out this:
subgraph starting at alsa-jack.jackP.3635.0 timed out (subgraph_wait_fd=7, status = 0, state = Running)
What I want to note is that there is a fix to that and I would like it to be included in the tree. I'm not sure if it doesn't break anything else, but it works for me ok.
Open pcm_jack.c and on the line 146 you'll find:
write(jack->fd, buf, 1); /* for polling */
Deleting this seems to get rid of the problem. So please if you can patch this out. (I didn't make a patch myself since this is so tiny fix that it isn't really worth.)
Cheers.
At Sat, 19 May 2007 15:44:45 +0200, Jasiu wrote:
Hi.
I want to note that JACK plugin in alsa-plugins in broken. (At least on my two systems.) It just plays for a few seconds and then stops hanging the application that was sending data to it. When it hangs jackd spits out this:
subgraph starting at alsa-jack.jackP.3635.0 timed out (subgraph_wait_fd=7, status = 0, state = Running)
What I want to note is that there is a fix to that and I would like it to be included in the tree. I'm not sure if it doesn't break anything else, but it works for me ok.
Open pcm_jack.c and on the line 146 you'll find:
write(jack->fd, buf, 1); /* for polling */
Deleting this seems to get rid of the problem. So please if you can patch this out. (I didn't make a patch myself since this is so tiny fix that it isn't really worth.)
It's always worth to make a patch. A patch contains some contexts around the changed line, so it's more robust than giving just a line number.
At Sat, 19 May 2007 16:54:45 +0200, Jasiu wrote:
Sorry, it seems that while that fixed the problem for some apps (notably mplayer) it broke a few others. (amarok, artsd) So please just ignore my remake about the fix for now. It would be nice if someone could explain to me why that bug happens, because currently I'm more and more confused about that.
Possibly a difference of running mode, mmap or not? Or, it might requires some special period or buffer sizes.
Since mplayer uses libao, some other apps like ogg123 or mpg321 should face the same problem. Could you check it? If yes, it's much easier than debugging with mplayer. The source code of mplayer is... well, you can judget after seeing it by yourself :)
Takashi
Unfortunately, mpg321 doesn't exhibit similar problem. I've also tested aplay changing various options (mmap, nonblocking, period, buffer, etc.) to no avail. Whatever I feed to the plugin works ok, except mplayer. If I'm not mistaken WINE did the same thing as mplayer when I checked some time ago - I'm not sure if it still does, but not much has changed probably. It could be as well bug in these applications, but other plugins work ok with them so jack one should do the same, I quess.
Yes, I'm aware of mplayer's subpar code quality. I've looked there a few times - it isn't the most bizzare code I've ever seen, but it's certainly not pretty. =)
Thanks for the reply.
On 5/21/07, Takashi Iwai tiwai@suse.de wrote:
At Sat, 19 May 2007 15:44:45 +0200, Jasiu wrote:
Hi.
I want to note that JACK plugin in alsa-plugins in broken. (At least on my two systems.) It just plays for a few seconds and then stops hanging the application that was sending data to it. When it hangs jackd spits out this:
subgraph starting at alsa-jack.jackP.3635.0 timed out (subgraph_wait_fd=7, status = 0, state = Running)
What I want to note is that there is a fix to that and I would like it to be included in the tree. I'm not sure if it doesn't break anything else, but it works for me ok.
Open pcm_jack.c and on the line 146 you'll find:
write(jack->fd, buf, 1); /* for polling */
Deleting this seems to get rid of the problem. So please if you can patch this out. (I didn't make a patch myself since this is so tiny fix that it isn't really worth.)
It's always worth to make a patch. A patch contains some contexts around the changed line, so it's more robust than giving just a line number.
At Sat, 19 May 2007 16:54:45 +0200, Jasiu wrote:
Sorry, it seems that while that fixed the problem for some apps (notably mplayer) it broke a few others. (amarok, artsd) So please just ignore my remake about the fix for now. It would be nice if someone could explain to me why that bug happens, because currently I'm more and more confused about that.
Possibly a difference of running mode, mmap or not? Or, it might requires some special period or buffer sizes.
Since mplayer uses libao, some other apps like ogg123 or mpg321 should face the same problem. Could you check it? If yes, it's much easier than debugging with mplayer. The source code of mplayer is... well, you can judget after seeing it by yourself :)
Takashi
participants (2)
-
Jasiu -
Takashi Iwai