Building an open embedded audio applicance.

[Russ White]

There should never be a need to use an async reclocker if the source is clocked accurately to begin with.

 

[barrows]

yup

There should never be a need to use an async reclocker if the source is clocked accurately to begin with.

Sure, no disagreement there. But, I would suggest that any oscillator sharing a ground with a BBB or RasPi is not going to be operating at its lowest possible phase noise. If one were to go to extremes of using a low phase noise oscillator(s) like CCHDs or NDKs to get the best out them, I would suggest isolators and separate supplies, and then re-clocking (as the isolators add jitter). All I am trying to say, is that the approach needed for best performance is not really different than what is required with USB if one is looking for the lowest possible source jitter.

 

[clivem]

I think it is entirely unrealistic to expect low jitter from a commercial computer MoBo.

<sarcasm>
But unrealistic is what these threads are all about! People buy a "cheap as chips" ARM dev board and then expect the clock(s) (being used for clocking the I2S output) on that board to be of "audiofool" quality.

I keep laughing every time I read some comment of how fantastic the I2S out of the RPi is, and how it easily bests....... A fractional divider from 19.2MHz for 44k1 and multiples.... Right, OK. When will people realise that there is no free lunch to be had!

Want a good I2S out of one of these ARM devices.... Isolate it. Re-clock it. Use "audio" quality, not "industrial" clocks. That's when you realise that you might have well just carried on using a decent, isolated, async USB interface, with "audio" quality clocks on board. (Which is what I think barrows was already trying to point out.)
</sarcasm>

 

[stijn001]

@Barrows, I think you were being quite critical in your arguments on what is being discussed in this thread, so I was just being equally critical of what you were writing. I hope you don't mind, sorry if you did.

I'm still genuinely intrested on your thoughts on the matter. But, yes, we are talking "embedded"

Personally I'm not even intrested in the NAS/Ethernet part as I'm looking to use a SSD in the box as well.

 

[nige2000]

<sarcasm>
But unrealistic is what these threads are all about! People buy a "cheap as chips" ARM dev board and then expect the clock(s) (being used for clocking the I2S output) on that board to be of "audiofool" quality.

I keep laughing every time I read some comment of how fantastic the I2S out of the RPi is, and how it easily bests....... A fractional divider from 19.2MHz for 44k1 and multiples.... Right, OK. When will people realise that there is no free lunch to be had!

Want a good I2S out of one of these ARM devices.... Isolate it. Re-clock it. Use "audio" quality, not "industrial" clocks. That's when you realise that you might have well just carried on using a decent, isolated, async USB interface, with "audio" quality clocks on board. (Which is what I think barrows was already trying to point out.)
</sarcasm>

ya that makes sense to me
this cape/bbb combo still should be no slouch though

is it possible to build a bbb,rpi,udoo etc etc type device from scratch to audio specs in hope to provide the cleanest jitter free i2s available?

 

[barrows]

No worries.

@Barrows, I think you were being quite critical in your arguments on what is being discussed in this thread, so I was just being equally critical of what you were writing. I hope you don't mind, sorry if you did.

I'm still genuinely intrested on your thoughts on the matter. But, yes, we are talking "embedded"

Personally I'm not even intrested in the NAS/Ethernet part as I'm looking to use a SSD in the box as well.

It is all good. My point was to suggest that for best performance, either approach will work, just that implementation and attention to the details are essentially similarly demanding for both approaches.

 

[glt]

At least it is now possible to get i2s out of a motherboard

 

[nige2000]

At least it is now possible to get i2s out of a motherboard

wont that have the same problems?

oh you didn't mean pc motherboards?

 

[Russ White]

An SoC solution is not really a "motherboard" and I think people are really getting lost in the weeds. Glt is right - at least we have a very solid place from which start.

Lets get back to the task at hand.

My goal is to start with the things I know we will need, and then possibly iterate later. We need to prove some basic concepts and driver ideas, so lets start with good platform to use for that progress.

The goal of this cape is indeed top notch audio - but another goal is reasonable cost etc, so I am not going to go too crazy here - at least for the first iteration. I just want to have a solid test bed.

 

[Supersurfer]

Hi,

This is a very interesting thread, and exiting developments.

I have some thoughts on the clock topic: I have used an accurate, low jitter, clock (Tent) to force accurate clocking on a Philips CD-Pro loader. I connected the Tent clock parallel to the exixting clock on the board of the CD-pro, according to Tent labs this will force the board clock to follow the accurate clock. In his way there is no need to desolder smd clocks from multi layered printing boards with the risk of destroying.

This might also be possible on an embedded plaform like BBB or Pi.

Regards,

 

[nige2000]

Hi,

This is a very interesting thread, and exiting developments.

I have some thoughts on the clock topic: I have used an accurate, low jitter, clock (Tent) to force accurate clocking on a Philips CD-Pro loader. I connected the Tent clock parallel to the exixting clock on the board of the CD-pro, according to Tent labs this will force the board clock to follow the accurate clock. In his way there is no need to desolder smd clocks from multi layered printing boards with the risk of destroying.

This might also be possible on an embedded plaform like BBB or Pi.

Regards,

i think thats the plan,
the bbb is supposed to work as clock slave,
don't think it would be as easy on rpi

 

[chevron]

Buffalo 32S and Raspberry Pi I2S

I have just got a Raspberry Pi and am using it with Volumio and the built in analogue out is working fine.

So can I now connect my Buffalo 32S through I2S like this as well?

And would I be right in thinking the connections should be

P5/3 (Bit_Clock) > B32S/DCK
P5/4 (Word_Clock/LRCK) > B32S/D1
P5/6 (Data_Out) > B32S/D2



QUOTE=Russ White;3806457]

Recently however the folks behind Raspbian and especially Florian Meier with his contributions to I2S modules have made me take a much closer look at the raspberry pi - particularly "model B - revision 2". The addition of P5 and the newest Raspbian and Volumio builds make it possible to have an incredibly good I2S based music appliance by simply adding a great DAC - such as the Buffalo III-SE - which works perfectly - but you could just as well use any asynchronous I2S input DAC.

Using the raspberry pi with the B3SE is very simple. I have tested two scenarios - each with distinct advantages.

First pi -> DAC direct.

This is really simple:

just wire P5 to the DAC appropriately - as show in the attached picture. Pin 1 is indicated on the rpi by the square pin. And P5 is located right next to P1 (directly below with P1 oriented at the top).

The best news is once configured you can use the pi as an airplay receiver (with a mac) for audio (at 44.1khz) and as a direct audio appliance at up to 192/32bit sample rate (the limit of ALSA at the moment).

I have mine streaming directly from NAS (an ASUS RT-AC66U with a USB SSD drive) at up to 192Khz sounding superb! No complaints. The sound is incredible.

The second method I will introduce if there is enough interest.

Here is detail you will want if setting up Raspbian, or Volumio for B3SE.

make your /etc/modules file looks like this:

snd_soc_bcm2708
snd_soc_bcm2708_i2s
bcm2708_dmaengine
snd-soc-pcm1794a
snd_soc_rpi_dac

I am happy to help anyone who has any further questions on how to make it work.

You won't be disappointed with the results.

I have developed two different USB -> I2S modules, and I have yet to find any reason to use one of those over this much more direct approach. Especially for the Buffalo III-SE.

Cheers!
Russ[/QUOTE]

 

[JLOP]

The second method I will introduce if there is ...

Please dô

 

[glt]

Testing with BII

Confirmed it requires the x128 multiplier for the DPLL, otherwise, there are hiccups.

Playing 384K shows the following message: underrun!!! (at least 15.824 ms long)

 

[DQ828]

Personally I'm not even intrested in the NAS/Ethernet part as I'm looking to use a SSD in the box as well.

I'd be very interested to know how you intend getting the SSD connected to the BBB, your not alone on that front.

 

[Goto]

I think it is entirely unrealistic to expect low jitter from a commercial computer MoBo. These boards are designed to be as cost conscious as possible, not be an audiophile quality product, and the clock derivation is probably quite poor, and the power supply running that clock will be full of processor noise.
Of course, there are those that feel the re-clocking onboard the ESS chip "solves" these problems, but this is not my experience: in my experience, even the ESS chip with the ASRC active and a 100 MHz local CCHD clock sounds much better to me when fed with a low jitter I2S source.
So far Russ has suggested that his "cape" design will re-clock the I2S signal with local low jitter oscillators. If the cape is well implemented, he should be able to produce an I2S data stream with jitter levels very near the inherent jitter of the chosen oscillators (and their power supplies). One could also use an asynchronous re-clocker like Ian's FIFO to reduce the jitter before the DAC.
Or, since this adds so much complexity, one could just return to using a really good asynchronous USB interface, which can achieve the same thing when well implemented.

All good points, but missing the simple one:

Out of the box, using the same linear PSU, the same length of wire for the I2S feed into the Buffalo, the same wireless card and server, music played via the Buffalo and RPi does not suffer dropouts and when the RPi is replaced with the BBB it does.

I happen to prefer the sound coming out of the BBB/Buffalo-II combo, it seems marginally more relaxed and coherent.

I fail to see how any USB Async interface could improve the performance. There is a whole other world of packetisation and driver handling involved in doing that just to get the bits out to the USB interface, then unpacking and reassembling the stream at the other end. Hardly purer, which was how I interpreted the purpose of Russ' approach here - by keeping paths short and processes minimal it becomes easier to refine the engineering and get the desired result.

If I was going to stick with Asynch USB I'd stick with a full-on Intel computing platform with grunt to spare.

Buffering and reclocking are last resorts, surely. If you can get the source to output a low jitter signal that has to be the simpler, more elegant and desirable approach.

I don't have access to the highend lab gear needed to test the jitter performance of this kit. So I reported my anecdotal experience and interim conclusion: Out of the box, in the same environment, the RPi delivers a more useable output than the BBB. It will be interesting to see what can be achieved longer term as the engineering improves.

 

[stijn001]

I'd be very interested to know how you intend getting the SSD connected to the BBB, your not alone on that front.

The UDOO platform has a build in SATA interface so that would be optimal for embedded HDD. However there is still the search for a I2S UDOO driver and we’ve therefor not yet have had anybody being able to comment on the performance of the UDOO using the I2S interface (as far as I know). The RPI and BBB routes require a USB to SATA conversion which will limit throughput but still be plenty fast enough for up to DSD playback (+/- 9Mbps) & brings us back to the dreaded USB interface. However the Mass storage device driver for a USB drive just pushes bits and doesn’t interfere in the way an USB audio driver does. Which is where a lot of the problems with USB audio interfacing originate from. Just the other day I disabled all Windows audio “services”, as Foobar will works directly with a A-synchrone wasapi driver. This made a clear audible difference, more relaxed and detailed. There is still a lot of scope for improvements in the software/driver department which is why I think projects like Volumio (an audiophile, purpose build stripped down OS) in conjunction with the work Russ is doing, have great potential.

The reason I want to go the SSD route is the fact that, Ethernet interfaces, either fixed or wireless, are adding inherent latency/buffering, interference and load/processes. Not to mention application protocol competability issues. I.e. another layer of complexity and potential issues, we can get rid of.

 

[DQ828]

What I’ve, thus far, have been able to find out is that the UDOO platform has a build in SATA interface so that would be optimal. However there is still the search for a I2S UDOO driver and we’ve therefor not yet have had anybody being able to comment on the performance of the UDOO using the I2S interface (as far as I know). The RPI and BBB routes require a USB to SATA conversion which will limit throughput but still be plenty fast enough for up to DSD playback (+/- 9Mbps) & brings us back to the dreaded USB interface. However the Mass storage device driver for a USB drive just pushes bits and doesn’t interfere in the way an USB audio driver does. Which is where a lot of the problems with USB audio interfacing originate from. Just the other day I disabled all Windows audio “services”, as Foobar will works directly with a A-synchrone wasapi driver. This made a clear audible difference, more relaxed and detailed. There is still a lot of scope for improvements in the software/driver department which is why I think projects like Volumio (an audiophile, purpose build stripped down OS) in conjunction with the work Russ is doing, have great potential.

The reason I want to go the SSD route is the fact that, Ethernet interfaces, either fixed or wireless, are adding inherent latency/buffering, interference and load/processes. Not to mention application protocol competability issues. I.e. another layer of complexity and potential issues, we can get rid of.

Thanks for the reply.

 

[miero]

News from the ongoing BBB driver development with 384kHz data:
- (good) native playback of 384/24 FLAC file from network via Ethernet is fine
- (good) native playback of 384/24 FLAC file from SDcard is fine
- (buffer under-runs) native playback of 384/24 FLAC file from USB Wifi dongle Ralink MT7601U is NOT fine
- (buffer under-runs) resampling 192->384 or equalizing using SoX is NOT fine

Notice: 384kHz is not officially supported by SoC of BBB

This requires custom kernel and ALSA library, not yet available for download.

 

[linuxfan]

I'd be very interested to know how you intend getting the SSD connected to the BBB, you're not alone on that front.

This was discussed much earlier in this thread -
http://www.diyaudio.com/forums/twis...embedded-audio-applicance-11.html#post3816635
You will see that I already mentioned the CuBox and UDOO products.

The reason I want to go the SSD route is the fact that, Ethernet interfaces, either fixed or wireless, are adding inherent latency/buffering, interference and load/processes. Not to mention application protocol competability issues. I.e. another layer of complexity and potential issues, we can get rid of.

All good logic, but despite this, I suggest no one should assume that an embedded computer with direct drive access will necessarily yield superior SQ than accessing audio files over a network. Counterintuitive, yes maybe, but over the several years I have followed developments in this area (including earlier x86 solutions) time and again I have come across reports from credible sources noting exceptional results from network-based solutions - as subjective listening observations. Most recently, those "credible sources" include Russ White.
Again, see my comments in that earlier post, and Russ' response.