[Icecast] a dedicated audio encoder

Fri Jan 23 00:19:36 UTC 2015

Hi,

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.

Best,
Maarten

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
> up:
>
> # 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:
> http://wiki.linuxaudio.org/wiki/raspberrypi
>
> bests, u.
>
>
>
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>