yomguy/DeeFuzzer

streaming from alsa input

nim4n opened this issue · 12 comments

Hi I tried to stream alsa input (as mp3 file) with deefuzzer but I get this error:

Exception in thread Thread-2:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
self.run()
File "/usr/local/lib/python2.7/dist-packages/deefuzzer/station.py", line 625, in run
self.set_read_mode()
File "/usr/local/lib/python2.7/dist-packages/deefuzzer/station.py", line 530, in set_read_mode
self.title = self.current_media_obj[0].metadata['title']
IndexError: list index out of range

so I changed the Mp3 class(deefuzzer/tools/mp3.py) from:

self.bitrate = int(str(self.info.bitrate)[:-3])

to:

try:
self.bitrate = int(str(self.info.bitrate)[:-3])
except:
self.bitrate = self.bitrate_default

is there any better way?

ps: I'm using ffmpeg for converting input to mp3 file:

ffmpeg -f alsa -i hw:0,0 -acodec libmp3lame -ab 128k -ac 1 -ar 44100 -vn test.mp3

The pull request fixes the bitrate issue,but not the reference issue you saw. I'm working up a fix to address this issue now.

Crash is caused by an input file/stream not containing any metadata in a readable format.

The pull request noted now includes a fix for this issue (as well as future-proofing)

@nim4n can you load up the latest dev branch and confirm/deny that this fixed your issue?

@achbed I use dev branch and I get this error:

Exception in thread Thread-4:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
self.run()
File "/usr/local/lib/python2.7/dist-packages/DeeFuzzer-0.6.6-py2.7.egg/deefuzzer/station.py", line 760, in run
if not self.icecastloop_nextmedia():
File "/usr/local/lib/python2.7/dist-packages/DeeFuzzer-0.6.6-py2.7.egg/deefuzzer/station.py", line 727, in icecastloop_nextmedia
self_err('icecastloop_nextmedia: Error: ' + str(e))
NameError: global name 'self_err' is not defined

GAH. ok - fixing now.

That's odd. I'm in the dev branch and that's not at all what I have on line 727 or 760. Which dev branch are you looking at?

sorry I was on master branch, after using dev branch I got this error in log file:

2015-01-28 09:16:56,764 INFO Core: Started station Station 0 
2015-01-28 09:16:56,764 INFO Core: Writing M3U file to :    /home/niman66/Temp/deefuzzer/mystation.m3u
2015-01-28 09:16:56,766 INFO Station http://localhost:8000/my_station.mp3: Channel available.
2015-01-28 09:16:56,766 INFO Station http://localhost:8000/my_station.mp3: channel connected
2015-01-28 09:16:56,767 INFO Station http://localhost:8000/my_station.mp3: Generating new playlist (1 tracks)
2015-01-28 09:16:56,778 ERROR Station http://localhost:8000/my_station.mp3: icecastloop_nextmedia: Error: 'MediaBase' object does not support indexing
2015-01-28 09:16:56,778 INFO Station http://localhost:8000/my_station.mp3: Something wrong happened in icecastloop_nextmedia.  Ending.
2015-01-28 09:16:56,779 INFO Station http://localhost:8000/my_station.mp3: channel closed

my xml is:

<'station'>
<'infos'>
<'short_name'>my_station<'/short_name'>
<'name'>My best funky station<'/name'>
<'description'>My personal best funky playlist ever !<'/description'>
<'url'>http://localhost<'/url'>
<'genre'>Various Funk Groove<'/genre'>
<'/infos'>
<'server'>
<'type'>icecast<'/type'>
<'host'>localhost<'/host'>
<'port'>8000<'/port'>
<'sourcepassword'>admin<'/sourcepassword'>
<'public'>0<'/public'>
<'/server'>
<'media'>
<'dir'>/home/niman66/ogg/<'/dir'>
<'format'>mp3<'/format'>
<'bitrate'>128<'/bitrate'>
<'ogg_quality'>7<'/ogg_quality'>
<'samplerate'>44100<'/samplerate'>
<'voices'>2<'/voices'>
<'shuffle'>1<'/shuffle'>
<'/media'>
<'rss'>
<'dir'>/home/niman66/Temp/deeF/<'/dir'>
<'enclosure'>0<'/enclosure'>
<'media_url'>http://localhost:8000/media/<'/media_url'>
<'/rss'>
<'/station'>

Pull request to fix this (and more regression issues with MediaBase) incoming.

Pull request #58 fixes the crashing issue. For now, you can jump over to my dev branch if you need to get this running immediately.

OK, thanks a lot

If the @achbed's patch is very welcome and fixes indeed the lack of metadata in this special use case, I have to say I disagree with the methodology used here for streaming the live audio source in many aspects:

  • first ffmpeg is useful (I use it a lot) but it's not really designed for live situations IMHO. My dev team had included itself the JACK driver to the main project some years ago, but we've never really manage to get a very stable in a realtime use case for very uptime values.
  • the deefuzzer file reader is not really made for reading a live stream. You should use the relay mode which needs an URL, not a file.
  • your hack may work in some cases by delaying the start of deefuzzer from the start of ffmpeg with at least one buffer in time. But the pb is that you can never know how is your buffer state...
  • last but not least, if you station hangs for any reason (network fail for example), your stream will restart at the beginning of the file :( Maybe you could avoid this with a FIFO.

Here is our prefered method at Parisson to stream from a soundcard:

  • use GStreamer to stream on a local icecast server:

gst-launch-0.10 jackaudiosrc connect=1 ! audio/x-raw-float, channels=2 ! queue ! audioconvert ! queue ! lamemp3enc quality=4.0 ! queue ! shout2send ip=127.0.0.1 port=8000 password=xxxxx mount=telecaster_live.mp3

with an ALSA source, it would become something like:

gst-launch-0.10 alsasrc ! audio/x-raw-float, channels=2 ! queue ! audioconvert ! queue ! lamemp3enc quality=4.0 ! queue ! shout2send ip=127.0.0.1 port=8000 password=xxxxx mount=telecaster_live.mp3

  • Use deefuzzer in relay mode between the local and the remote servers. Use this option:
<relay>
 <mode>1</mode>
 <url>http://127.0.0.1:8000/telecaster_live.mp3</url>
</relay>   

The 2 main advantages of this approach is to some very stable (realtime with JACK) encoder threads and the local side, and a network dropout proof streaming using deefuzzer between the local and the remote servers.

Don't miss the point, it's cool if you find a method that works. But for all the previous reasons, I tend to think it will not on the long run...

Cheers