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...
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.
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.
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
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.
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.
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.
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.
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..)
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..)
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).
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).
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.
Yes yes, I remember all of those gadgets sadly just to fill the precious earth in a short time. Thank you for clearing my air. And now I finally have a USB device that makes digital bearable and can be connected to the latest fashion. Is it ironic that I can use a computer and USB, neither of which I love, to listen to Beethoven.
I don't own any 192k material, so I haven't tested. 96k was my goal. For the sake of science, I will make up some 192k test files to stress test the system, and see if removing the keyboard makes a difference to the results.
I suppose I agree, hence why I spent 4x as much money on Borge's USB DAC as I did on the R-Pi. It should be easy to drop in some other board, either ARM or x86, running Linux later. Hopefully the success of the Pi will inspire lots of competitors with USB that works
I totally sympathise with his design goals and so far I've been very pleased with the sound quality.
PS: Why use "IRQs per second" as a performance metric? Surely the interrupt rate doesn't matter, as long as you don't miss any of them. I expect there will be some critical interrupt rate beyond which the system falls apart, but any rate below that should work fine.
I thought the choice of a 16-sample packet for the UAC2 mode was a little small, but I assumed there was some other good reason for it.
Last edited:
For some sample files, go here: High Resolution Music DOWNLOAD services .:. FLAC in free TEST BENCH
Thanks for the link! I chose the Mozart's Violin Concerto no.4. I heard one definite glitch with the keyboard connected: a distinct pop during the quiet solo passage near the end, that wasn't there on rewinding.
With the keyboard disconnected, I thought I heard a few slight stutters, but I couldn't positively identify any of them. Could have been underruns, could have been edits in the recording or noises from the musicians. Once I got the "metallic noise" on disconnecting the keyboard, but it resolved itself after a few seconds.
Setting these issues aside, the recording is beautiful and really shows off the performance of the DAC.
I don't think I can do any better without hooking up a SPDIF output and capturing the digital data for comparison to the original. It won't be the first time that I "heard" things during a critical listening session that weren't actually there.
With the keyboard disconnected, I thought I heard a few slight stutters, but I couldn't positively identify any of them. Could have been underruns, could have been edits in the recording or noises from the musicians. Once I got the "metallic noise" on disconnecting the keyboard, but it resolved itself after a few seconds.
Setting these issues aside, the recording is beautiful and really shows off the performance of the DAC.
I don't think I can do any better without hooking up a SPDIF output and capturing the digital data for comparison to the original. It won't be the first time that I "heard" things during a critical listening session that weren't actually there.
Last edited:
scopeboy what firmware version AW you tested? I used last firmware with Børge changes and heared on 192/24 files glitches and "metallic noise" frequently.
I checked CPU loading:
44k < 10% total
192k < 30% total
I think that this is maybe firmware problem. Does anyone tested the latest firmware with 192/24 on linux desktops?
Just listened with my i7 Sandy Bridge laptop with latest Borge firmware
192/24 no problems at all. (In fact, no problems on Linux platform using mpd for a long long time with older versions of firmware.)
Alex
I'm using whatever firmware Borge shipped out on the unit last week.
I fiddled with the Pi's /boot/config.txt in an attempt to disable CPU clock management and run it at full speed all the time. I wonder if that is helping. If you're interested, I'll post details in the Raspberry Pi thread this evening.
I fiddled with the Pi's /boot/config.txt in an attempt to disable CPU clock management and run it at full speed all the time. I wonder if that is helping. If you're interested, I'll post details in the Raspberry Pi thread this evening.