ogg123 buffer write failed writing to FIFO

[James Wyper]

Binary package hint: vorbis-tools

I use mediatomb (the official Ubuntu package) as a UPnP server. My music files are stored as flacs, which my player can't read so I use mediatomb's transcoding feature which calls ogg123 -d wav -f xxxx some_music.flac

mediatomb sets up xxxx as a FIFO and reads the transcoded music from that. It used to work fine on Hardy but now I've upgraded to Intrepid the music will cut out after 15 seconds.

If I transcode the file directly using ogg123 (e.g. ogg123 -d wav -f some_music.wav some_music.flac it works fine. If however I try

mkfifo /tmp/test

ogg123 -d wav -d /tmp/test some_music.flac

and then use e.g. vlc in another terminal to read the transcoded data from /tmp/test

ogg123 will hang until vlc starts reading from the FIFO then fail with "error. buffer write failed". So mediatomb is not part of the problem.

I note that ogg123 changed from 0.11.1 to 0.12.0 as part of the upgrade to Intrepid. For now I've switched to transcoding using mplayer (which is slower to start up) as a workaround. (See https://sourceforge.net/forum/forum.php?thread_id=2980305&forum_id=440751 )

Thanks,
James.

[Gregory Meyer (greg-gkmeyer)]

Here is the same bug in the debian bugtracker.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509376

It's happening to me here too. I'm just using ogg123 in a shell script to convert some oggs to mp3s and a couple of tracks each album affected by this. After a couple of tries it works okay. Very hard to reproduce and doesn't always happen on the same file or in the same place in the file.

Using 9.04

[Dave Brady (matter-grey)]

I spent most of my night trying to track down the cause of this not working. I'm giving up now, but I thought I would mention this tidbit (apologies, it's very late, and I don't have time tonight to figure out the bug fix submission process). One of the patches applied to vorbis-tools contains this snippet of code:

@@ -251,6 +251,11 @@
       write_amount == buf->curfill ? buf->eos : 0,
       buf->write_arg);

+ if (!write_amount) {
+ DEBUG("Error writing to the audio device. Aborting.");
+ buffer_abort_write(buf);
+ }
+
     LOCK_MUTEX(buf->mutex);

     buf->curfill -= write_amount;

This is correct, except for the case where write_amount starts out as zero, which happened a couple of times while I was trying to test this. It's very possible that Gregory's problem is a result of this bug. It shouldn't abort the buffer write if the write_amount is zero to begin with. It's an easy enough fix to make. Just wrap the whole thing in an if.

As for the bug at hand in this report, it's unrelated, and I have no idea. libao is returning an error in ao_play() is all I know.

[bcrowell (launchpadcrowell07)]

This is also affecting me on jaunty. This is a crippling bug.

$ uname -a
Linux rintintin 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:58:03 UTC 2009 x86_64 GNU/Linux

[jon_snow (jonsnow1357)]

as said in the Debian bug thread referenced a couple of posts ago a workaround is to add --audio-buffer 0 to the start options. It seems to work at least in my case (media server transcoding and streaming)

I hope somebody fixes this bug sooner

Best regards

[Martin Steghöfer (martin-steghoefer)]

This was reported as bug 509376 to Debian [1] and 1521 to Xiph [2]. It was fixed in 1.4.0 (upstream) and 1.4.0-1 (Debian & Ubuntu).

Cheers,
Martin

[1] https://bugs.debian.org/509376
[2] https://trac.xiph.org/ticket/1521