Building an open embedded audio applicance.

[PET240]

Not to be rude, but what question? That reads as a statement to me is all.

Chuz,


Drew.

 

[miero]

(technical details)

From the Linux sound interface ALSA side there are two DSD formats:
- SND_PCM_FORMAT_DSD_U8
- SND_PCM_FORMAT_DSD_U16_LE

With ability to play up to 352.8/384kHz it would be possible to play:
- DSD64 in U8 and U16_LE format (stereo)
- DSD128 in U16_LE format (stereo)

The DSD128 in U8 format will need to be transcoded to U16_LE format (automatically using ALSA plugin), because 705.6kHz is too much for BBB.

The .dsf or .dff should be handle by player, not the driver.

 

[linuxfan]

Sorry PET-240. I thought you were asking for confirmation.
Actually both .dff and .dsf support metadata, in a limited fashion.

 

[PET240]

Heya linuxfan,

My understanding of dsd is still limited and am on a learning curve as I am looking to record vinyl in dsd128 on a korg unit, be nice to play it back as a native without resampling etc, can you please provide details on what you know?

Miero,

That code is gobblygook to me, Im just gonna believe you know what you are doing.......waaaay outta my league!!!!
To learn something, can you please explain the U8 and U16 differences? and what the LE is ?

Regards the player, hence asking Russ if the Buff III will handle both the .dsf snd .dff file formats.

Really appreciate the major efforts with this!!!

Chuz,

Drew.

 

[miero]

PET-240: you should ask that question to developer of player ... not here

(more offtopic)
U8 vs U16 ... how many bytes is pushed to DSD channel ... U8 pushes 1 byte, U16 puses 2 bytes at once

 

[miero]

Regarding LCD capes. I've checked datasheets of 4 available LCD capes and none of them is without conflict with the audio cape:

LCD3: P9_27 (D4 vs USER_LED1), P9_30 (D1 vs GPIO3_16)
LCD4: P9_27 (D4 vs LCD_DISEN), P9_24 (MCLKSEL vs GPIO0_15), P9_26(D3 vs TSC_INT), P9_30 (D1 vs GPIO3_16)
LCD7: P9_30 is not routed (D1)
4D 4.3: P9_27 (D4 vs GPIO3_19), P9_24 (MCLKSEL vs GPIO0_15), P9_30 (D1 vs GPIO3_16)

The LCD7 seems to be the best possibility of these:
- it does not require to be connected at the top
- shares only one data pin with audio cape

This data pin is the first McASP data pin and. Pins are after recent change routed in the increasing order 1-2-3-4 which means that if driver would use only 2-3-4 then the I2S/DSD switching feature will not work.

So ... LCD7 might be usable after reconfiguring the driver, but the audio cape automatic I2S/DSD pin remapping would not be usable.

In other words, the one will need to switch cables manually.

 

[miero]

Another thing, I've not tested the audio with the HDMI output. But I'm sure it will be at least a bit slower. Which means, that DSD might not work either way.

 

[Russ White]

System overhead incurred by using the LCD cape seems a bit undesirable.

I would prefer remote UIs even a separate BBB

 

[clsidxxl]

Russ, Have you an idea of the clocks you want to put on the cape.

Hi Russ,it is still secret

 

[Russ White]

Sorry I simply forgot to answer

The plan is to use the CCHD-957

http://www.crystek.com/crystal/spec-sheets/clock/CCHD-957.pdf

 

[clsidxxl]

Russ,Have you considered the NDK NZ2520SD http://www.ndk.com/en/products/search/clock/1187929_1433.html ,excellent specification,but very very small.The CCHD-957 is very good ,I use it with the FIFO of Ian.

 

[ChrisMmm]

Russ,Have you considered the NDK NZ2520SD NZ2520SD(OA / AV)/Crystal Clock Oscillators/NDK ,excellent specification,but very very small.The CCHD-957 is very good ,I use it with the FIFO of Ian.

And, dare I say it, the NDKs are a lot cheaper. Depending on how you source them of course. From what I have read performance is similar.

But this isn't a democracy, Russ makes the choice and I would abide by that.

 

[PET240]

Regards the LCD and Russ looking at using the bbb to write to the registers on a dac(Buff III-refer earlier in the thread), could an lcd be connected via the spi bus? Or if a dac is connected that way can only one device be connected at a time?
Also, another software I used(mpdpup) would load two songs into ram(thats what I understood anyhoo), so when the first finished the second was ready to crank, the question I have is, could the sample rate and format be "read" by software and at end of song the dac registers could be changed if required to automagically be setup for whats coming next. I dont know delays or dramas, just spitballing.
An lcd isnt really necessary for this black duck, just my brain throwing ideas into the ether.

Russ, with the two clocks are we going to have a mclk u.fl term so we can run the buff synchronous if we desire? Be nice to have u.fl connectors for the i2s as I am looking at running through a fifo, though if you are reclocking on the cape this may not be at all necessary.

Thankyou again gents for your efforts, looking forward to hearing them!

Chuz,

Drew.

 

[acko]

I am a bit lost in this development. I'll have my BBB in two months, so I have to stick with the Rasberry Pi for the time being. I am enjoying it, using both the I2S and I2C to control the DAC. If there is interest I can share the results (that are kind of trivial) here or in a dedicated thread. What I am trying to do is to modify volumio to make it use I2C to control the volume. Now I manage to do it only with command line. Help is also appreciated.

Does the driver developed for BBB do the same ?

What's the final goal of the whole development ?

Thanks,

D.

Yes, agree, goals and clarifications needed!

This is a great project that Russ have initiated but we before we get carried away lots of development we need to look at it from other perspectives and the reasons for going about this way. My knowledge in Audio streaming is limited at the moment but reading between the lines the Embedded Audio Appliance is practically a duplication of established lifestyle products and I can see better systems out there in this regard.


But if Russ can come up with synchronous BBB cape then I am also in for it.

But then again if you already have Ian's FIFO this would make the 'cape' redundant and I reckon the FIFO is a better product for post processing. So for those who have an RPi and Ian's FIFO you practically have everything you need now for full sync operation onto ESS DACs. Plus VolumeIO, the convenience and performance is right in your hands now.

But the 'BBB Cape' can have other advantages (apart from being a compact add-on) that Russ could explain to us.

Sorry, I didn't mean to cast aspersions but I am just commenting from a technical point of view. Hope I can be proven wrong

 

[PET240]

Acko,

The only real downside is Ians FIFO doesnt do dsd, I have one of all his boards so am not dissing his efforts in any way. Since I am looking to record my vinyl in dsd I would like to be able to play it back natively in dsd as well.

Appreciate yoir thoughts and insights.

Chuz,

Drew.

 

[BrianL]

clsidxxl, ChrissMmm,

The NDK doesn't have close-in phase noise specs, and w/o that, it's hard to say whether they are worth messing with.

 

[acko]

Acko,

The only real downside is Ians FIFO doesnt do dsd, I have one of all his boards so am not dissing his efforts in any way. Since I am looking to record my vinyl in dsd I would like to be able to play it back natively in dsd as well.

Appreciate yoir thoughts and insights.

Chuz,

Drew.

Thanks, all for this cape then.
Great work!
Of course since the cape isolates and improve the clocking scheme we would expect this to provide super audiophile quality or am I expecting too much for a product like this?

 

[PET240]

I have a feeling Russ knows what people would be liking/wanting/requiring/dreaming/hoping for, so I would say he intends to the benchmark.......

Chuz,

Drew.

 

[4est]

If one likes their other products, we should have some faith that Russ and Brian will do it well. Russ made it clear that he wants this to be high quality in its first iteration.

 

[miero]

Raw BBB is able to generate only multiples of 48kHz frequency using very poor clock. So it is usable neither for CD nor DSD.

Raw RPi can generate both frequencies, but it drops some ticks to keep frequency accurate on average. And it does not support DSD, neither it has ability to use better clocks so no bit perfect.