[Icecast-dev] seamless looping mp3 files to icecast
Bob
bob at leanbackproductions.com
Tue Dec 13 07:58:15 PST 2005
Hello,
The previous message seems to confirm that I'm posting to the right
place - apologies if not.
I have a project where I'm streaming live software-generated PCM audio
to icecast via ices 2.0 stdinpcm - this works great for ogg vorbis
(thanks very much guys!)
I haven't been able to find a stdin-based solution for
PCM->mp3->icecast, is there one? From the docs, it looks like ices
0.4 can't do this. Piping PCM to lame to ezstream does work, but it
uses a lot more CPU than ices2/stdinpcm (10% compared to 0.5%) and has
some sync problems too.
Instead I've created VBR MP3 files with lame (of the 4-bar loops I'm
streaming) and I pipe these files repeatedly to ezstream->icecast.
This works OK but there's a tiny but noticeable gap as each file stops
and the next one starts. I guess this is something to do with
headers.
I get a small gap too with the vorbis equivalent [oggenc -> file
then repeatedly pipe the file -> ezstream -> icecast ; so I've
switched back to ices2/stdinpcm]. I even tried to hack oggenc to
create headerless (no headers or bos flag) and tailless (no eos flag)
ogg files, but these seemed to be ignored totally by ezstream or
icecast - they pass through without being recognised (not sure which,
sorry).
So, before I go hacking further (I guess I should try headerless MP3
files), does anyone have any suggestions? Which element in the chain
do I need to fool? Is it ezstream, icecast or the client player? If I
try to fake a constant stream from the contents of a single file, will
I have problems with the frame numbers resetting to zero at the
beginning of each loop? Or is there some pipe based, low CPU option I
can use.
thanks for your time,
cheers,
Bob.
PS. can anyone explain why ices2/stdinpcm uses a lot less CPU than
oggenc (0.5% compared to 10% when using 'ps aux').
More information about the Icecast-dev
mailing list