Open-source USB interface: Audio Widget

[RayCtech]

Originally Posted by scopeboy

Maybe a better question is: Where can I get this ARM board that has an ALSA driver for the onboard I2S peripheral? it would replace both the Pi and the USB-I2S.

I'll write about my Pi project in the other thread mentioned above when it's complete. I built a user interface based on a $16 backup camera monitor, an Arduino with an encoder and some buttons attached, and ncmpc (the console client for mpd) but I also like to use the Mpod client on my phone. Maybe I'll leave the UI out in the end.

A CuBox have been used until now. I2S must be tapped from the HDMI chip inputs. Kernel source must be modified to use the 3.5 ps jitter 0 ppm clock for all sample rates.

Now I have started the works with a prototype board with a iMX.6 quad core 2GB RAM, gigabit network, SATA etc.. The sound chip removed and I2S directly connected. CPU / system, network and USB 300 ppm crystals replaced with 20 ppm 1 ps jitter clocks. Audio (I2S) master clocks will either be re-clocked or 1ps jitter clock injected. A lot of work remains to perfect both hardware and kernel, ALSA and MPD...

[parisnight]

Originally Posted by RayCtech

But the internal I2S (ARM CPU) uses DMA effectively and are down to 10 IRQs pr. second with a 3.5 ps jitter / 0 ppm clock - SPDIF output at +- 30 ppm.

I think this is the reason why I am very happy with the widget as I had not heard good digital sound in my long life before. But do you feel confident in the 3.5 ps jitter measurement from the ARM fed with external clock? I guess it takes some skill to achieve this and as such becomes another project while the widget beckons now to enjoy.

[palmito]

Originally Posted by RayCtech

A CuBox have been used until now

Sorry for the OT question, so even without your modifications, the CuBox performed ok as streamer. I guess by "ok" I mean without the problems encountered by most of the RPi users? I had looked at the CuBox but didn't want to shell out the $160 to find out it also has usb/ethernet problems. I could not get the RPi to cleanly stream to the AudioWidget (although I didn't try the latest kernel recommendation from a few posts back). Thanks for any comments on this.

[nikkov]

Originally Posted by scopeboy

...
After some more listening, I've noticed occasional glitches (once per few minutes) when the USB keyboard is connected, even without touching any keys. I did some listening this morning with the keyboard disconnected, so all of the USB devices in the system were 2.0. I didn't hear any glitches.

How about glitches on 192/24 files? I tried play 192/24 from network storage with connected USB keyboard and heared frequently glitches. On 44100 all OK

[linuxworks]

the rpi is cute, and all; but I still rely on a mini-itx fanless pc.

it has no issues like these, at all, and needs no tweeks.

for 192k, I'm not sure I'd really trust the pi. I like the unit for 44/48 material, but 'high res' is kind of asking its usb system to perform like a real usb system (lol) and it just has trouble when asked to do a lot.

[1audio]

I would suggest using aplay -v to play a file from a NAS mount and watch for underruns. A 192K file may just need too much immediate response from the CPU. There are tricks for adjusting the priorities and using different governors that may help but that's getting pretty deep into the system and you may find yourself compiling new kernels.

[linuxworks]

plus, you always want extra headroom (in cpu) so that you are not pushed to the limit. a good system should not have to sweat and work too hard, just to pump audio out. and when people say that 'hitting a key on a usb keyboard' causes glitches, well, it sure sounds like the system is not quite ready to be pushed into usb-intensive work.

[MrSlim]

nyc_paramedic started this thread about using PCengine "alix" boards for mpd: Dead silent dedicated Linux music server for USB DAC's.
I think there might be a thread around here about it also. I think a board like that is a good compromise between something like an Rpi and a MiniITX board, from many perspectives (size, performance, silence, low power etc..)

[linuxworks]

the lesson, to me, is that engines (pc computers) will come and go. the rpi is teh new hotness right now, but before that I remember the seagate dockstar, the pogoplug, some other plastic boxes that could run a scaled down linux.

best would be to not be too tied to any one of them. let the tech mature as it will, over time. assume a usb interface and as that gets 'better' your solution will get better.

the pi could be 'yesterday's news' in a year or less. some new affordable board or system will try to displace it.

the itx intel (atom) box works very well and is small enough and buyable easily so that its not a problem using one or buying one. you don't wear out your sd-card (lol) but instead wear out your usb stick (if you boot that way) or ssd, both being much better for longer term writes than sd-card!

heck, you could actually run rmaa test suite using an itx box and 2 spdif ports or analog ports. the atom pc is slow but it can run that kind of audio test. I'd like to see that tried on a pie (and not laugh while it does it).

[RayCtech]

Originally Posted by linuxworks

plus, you always want extra headroom (in cpu) so that you are not pushed to the limit. a good system should not have to sweat and work too hard, just to pump audio out. and when people say that 'hitting a key on a usb keyboard' causes glitches, well, it sure sounds like the system is not quite ready to be pushed into usb-intensive work.

The CuBox have a total CPU load of 5% playing 44.1k from a NAS and below 20% load when playing 352.8/384k 32bit.. This is when MPD plays to both the internal I2S and two USB devices. The gigabit network and SATA are the "real thing" and not implemented over USB. The USB ports are even separate with each own IRQ and hardware. Be aware that the default kernels and MPD may contain bugs and may not be optimal. Have not checked the latest sources, but the MPD "status" report should not be trusted as it does NOT report correctly the compile time options and certainly not the runtime options, and you must check for bugs that steals resources. The FIFO output writing to the SD card was one of them. Had to modify the scripts to be able to compile MPD like I wanted as there are a lot of checks and "logic" that works agains you.
And the SD card are NOT connected via / over USB like in most of the crippled ARM systems.
However the CuBox are now retired and works have started with a iMX.6 quad core system.