[Icecast] a dedicated audio encoder
mcbicecast at robuust.nl
Fri Jan 23 00:19:36 UTC 2015
I managed to get my hand on a Xenyx x2222usb at a friend's, so I took the
opportunity to do some testing with it.
Pi model B, one of the more recent editions (I also had an older one from
just after they were introduced and that one had trouble rebooting when
attaching/detaching network so I ditched that one). Two usb onboard.
Xenyx x2222usb has the same usb chip 08bb:2902 Texas Instruments Japan
PCM2902 Audio Codec
usb 1-1.3: new full-speed USB device number 4 using dwc_otg
usb 1-1.3: New USB device found, idVendor=08bb, idProduct=2902
usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.3: Product: USB Audio CODEC
usb 1-1.3: Manufacturer: Burr-Brown from TI
input: Burr-Brown from TI USB Audio CODEC as /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3:1.3/input/input0
hid-generic 0003:08BB:2902.0001:input,hidraw0: USB HID v1.00 Device [Burr-Brown from TI USB Audio CODEC ] on usb-bcm2708_usb-1.3/input3
usbcore: registered new interface driver snd-usb-audio
Started with a 3.10.25+ kernel that happened to be on an earlier install.
When doing mpg123 -D hw:1,0 something.mp3 it spammed lost of
Jan 22 20:33:11 testpi kernel: [2316881.058933] delay: estimated 0, actual 132
Jan 22 20:33:11 testpi kernel: [2316881.066876] delay: estimated 0, actual 133
etc etc in the logs and playback was choppy.
Didnt even bother recording, but went for an apt-get update / dist-upgrade
which installed (among others) a new rpi-update, and running rpi-update
gave me kernel 3.18.3+
After a reboot, playback worked like a charm, no pops, clicks, ticks, just
perfect playback. No messages in syslog either.
Then I tried: arecord -D hw:1 -f cd testrec.wav
But as soon as something other than silence was sent to the device, lines
like these started to show up:
Jan 22 23:17:48 testpi kernel: [ 9190.974009] Transfer to device 4 endpoint 0x4 frame 1697 failed - FIQ reported NYET. Data may have been lost.
Jan 22 23:17:48 testpi kernel: [ 9191.093025] Transfer to device 4 endpoint 0x4 frame 1816 failed - FIQ reported NYET. Data may have been lost.
Jan 22 23:17:49 testpi kernel: [ 9191.362062] Transfer to device 4 endpoint 0x4 frame 37 failed - FIQ reported NYET. Data may have been lost.
Jan 22 23:17:52 testpi kernel: [ 9194.366470] Transfer to device 4 endpoint 0x4 frame 993 failed - FIQ reported NYET. Data may have been lost.
Jan 22 23:17:52 testpi kernel: [ 9194.419477] Transfer to device 4 endpoint 0x4 frame 1046 failed - FIQ reported NYET. Data may have been lost.
Jan 22 23:17:52 testpi kernel: [ 9194.653508] Transfer to device 4 endpoint 0x4 frame 1280 failed - FIQ reported NYET. Data may have been lost.
And recordings were choppy, clicking etc.
This is all running the Pi at normal setup with USB2 enabled and Xenyx USB
directly connected to the Pi with a 1.5m usb A-B cable.
Then, I connected a usb hub to the Pi and then the Xenyx USB to the hub.
Unpowered el cheapo hub. Tried another al cheapo crappy usb2 hub that
never worked when connecting it between a UMTS dongle and a PC (dongle
just would get up and running, probably power issues). Both did the magic
trick: recording now works like a charm.
Once did I see an "overrun!!! (at least 1055.346 ms long)" but that was
probably something from arecord not being able to save the recording to SD
card fast enough because I was doing other stuff with the SD card at the
same time. Nothing in syslog, just output from arecord / alsa lib.
So, conclusion: PCM2902 works with pi for both playback and recording, as
long as you connect it through some random USB2 hub. Doesn't draw much
power, but maybe you need a hub's extra capacitors to prevent spikes from
causing problems at the pi. Of course, I suppose using it through a
powered hub such as the PiHUB should also work.
The only thing I kinda missed was a recording level control. The only
control alsamixer is giving me, is the pcm playback level. So you'd have
to make sure the audio you send to it is somehow sane.
On Thu, 22 Jan 2015, unosonic wrote:
> Maarten Bezemer:
>> Shouldn't USB2.0 ports be able to connect to USB1.1 devices without
>> changing the entire stack to USB1?
> according to my experience, no. here are my personal notes when i'd set it
> # Xenyx 302 USB
> pi at raspi ~ $ lsusb
> Bus 001 Device 005: ID 08bb:2902 Texas Instruments Japan PCM2902 Audio Codec
> pi at raspi ~ $ cat /proc/asound/cards
> 1 [CODEC]: USB-Audio - USB Audio CODEC Burr-Brown from TI USB Audio CODEC at usb-bcm2708_usb-1.3, full speed
> pi at raspi ~ $ arecord -l
> **** List of CAPTURE Hardware Devices **** card 1: CODEC [USB Audio CODEC], device 0: USB Audio [USB Audio]
> Subdevices: 1/1 Subdevice #0: subdevice #0
> # My Notes: force USB 1.1 device, in /boot/comdline.txt: dwc_otg.speed=1
>> Can the Xenyx USB mixers be attached as USB2.0 and do these work reliably?
> the Xenyx 302 USB is 1.1 and didn't work reliable for me. Maybe that can be
> tweaked so that it works, but i wasn't able... no idea how the other Xenyx'
> work. My conclusion was that 2.0 devices are fine, 1.1 not because of the Pi's
> internal mess... but there may be workarounds, see:
> bests, u.
> Icecast mailing list
> Icecast at xiph.org
More information about the Icecast