• Disclaimer: This Vendor's Forum is a paid-for commercial area. Unlike the rest of diyAudio, the Vendor has complete control of what may or may not be posted in this forum. If you wish to discuss technical matters outside the bounds of what is permitted by the Vendor, please use the non-commercial areas of diyAudio to do so.

Building an open embedded audio applicance.

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
...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..

Networking happens to be my field of expertise. The point I was making was with regards to "another layer of complexity and potential issues”. But off-course you are absolutely right, networking can yield excellent results if done right. No question about that.
 
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.

Great Miero!

Which kernel version are you using now?
Have you tried Realtime kernel?

I have MUCH better audio performance on RT kernel vs standard kernel on PC with same system settings. IMHO the same positive effect should be on SoC (BBB, Cubietruck, Rpi, Wandboard, UDOO...)

Cheers
 
Ah, I'll try RT kernel, thanks for reminding :)

Currently this one:

# uname -a
Linux alarm 3.13.6-3-ARCH #4 SMP Fri Mar 28 01:27:56 CET 2014 armv7l GNU/Linux

Hi miero, noting the above just wondering if you are basing you development around Archlinux now? Are you expecting to settle on one distro and kernel version as an end point or are you intending leaving that entirely up to the user? Or maybe you haven't considered this!

I had started with Archlinux 3.12 but had some difficulties so went for the standard BBB eMMC Debian image. Seems to me Archlinux is kept more up to date than Debian in terms of Linux kernel but has a smaller user community than Debian.

I think its pointless my switching to Archlinux at this time till things have settled down especially if you are planning on trying an RT kernel, just keen to keep up with the play!
 
Yes I know, but I'm interested in the BBB not the Cubox or the UDOO, maybe the Cubietruck though. I have read the whole thread.

I came very close to ordering a Cubietruck (luckily out of stock at the time) but having dug a bit deeper decided the BBB with the promised cape (Cape of Good Hope!) had the best chance of high end SQ given Cubietruck has a PLL derived clock.
 
Last edited:
I came very close to ordering a Cubietruck (luckily out of stock at the time) but having dug a bit deeper decided the BBB with the promised cape (Cape of Good Hope!) had the best chance of high end SQ given Cubietruck has a PLL derived clock.

Thank you, I too came very close to buying the Cubietruck, and like you are waiting for the Cape of Good Hope :)

I'd still like to be able to attached a SSD without using the USB if possible (I know Russ is not interested in such things) but I don have the knowledge to work out how to go about it.
 
I’ve placed a pre-order for the BBB. Now my quest is for a suitable power supply.

Palmito suggested to me that, include the cape and possible other features in use, power consumption could well be above 1A. What HQ/low noise power supply would you recommend?

What’s the expected power consumption with the cape (being developed by Russ) and a SSD connected via USB + possibly Ethernet for remote control/management?
 
Last edited:
The most power hungry devices on the cape will be the clocks - and only one will run at a time they should consume < 25ma. Along with the other active parts total consumption should be well below 100ma. Of course the design is subject to change still. :) As it stands now that is accurate. :)

Thanks Russ, would you dare making a ball park power consumption estimate for the whole BBB including, your cape, SSD and Ethernet, like I mentioned earlier? Maybe you have some way of quickly testing this.

As I suspect the whole thing will need to be powered through the one 5Vdc input on the BBB board, I'm still not sure which low noise power supply would be most suitable.
 
Thanks Russ, would you dare making a ball park power consumption estimate for the whole BBB including, your cape, SSD and Ethernet, like I mentioned earlier? Maybe you have some way of quickly testing this.

As I suspect the whole thing will need to be powered through the one 5Vdc input on the BBB board, I'm still not sure which low noise power supply would be most suitable.

I would suggest using a powered USB hub for the SSD. Those things have very spiky current draw.
 
I came very close to ordering a Cubietruck (luckily out of stock at the time) but having dug a bit deeper decided the BBB with the promised cape (Cape of Good Hope!) had the best chance of high end SQ given Cubietruck has a PLL derived clock.

very interesting, may you please explain or give me a reference, I must have missed something somewhere...

Are there other amongst the small boards that share the same issue (I mean Udoo, Cubox-i, Wandboard, ...

When is the crossing of the Cape of Good Hope planned Russ (approximately ? price tag ?).

Is it compatible with both Volumio and RuneAudio or other system ?

And a last question I am using a Najda digital XO (see thread on http://www.diyaudio.com/forums/digital-line-level/215379-dsp-xover-project-part-2-a-68.html
Would the cape be able to provide a clock to Najda. It is resampling inputs to 48 kHz or 96 or 192 kHz

BR
Jean-Louis
 
The most power hungry devices on the cape will be the clocks - and only one will run at a time they should consume < 25ma. Along with the other active parts total consumption should be well below 100ma. Of course the design is subject to change still. :) As it stands now that is accurate. :)

Would having a completely separate supply for the cape be beneficial? Or is it so interlinked with the BBB that trying to isolate it is just not worthwhile?
 
Would having a completely separate supply for the cape be beneficial? Or is it so interlinked with the BBB that trying to isolate it is just not worthwhile?

I was kinda assuming there would be an option for either separate power or from the BBB on the cape. I have built a box with the BBB and one of these Curryman DAC (ES9023) | MiniDSP connected via I2S. I have included a separate 5V supply for the cape when it arrives. Thats anticipation for you!

It sounds good already with 48/96k input and quite acceptable with 44.1k much to my surprise. ALSA doing a good job of up-sampling I guess.
 
Last edited:
Fantastic work guys!
I just finished the BBB image I promised you:
1- MPD 18.9
2- Alsa-DSD Player included
3- Miero's i2s driver included (fantastic work mate!).

I also set up a volumio repo, where you could find latest MPD (both for PI and for other platforms, and the Alsa-dsd player.

To install alsa-dsd-player:

sudo apt-get update
sudo apt-get install alsa-dsd

The syntax is:

alsa-dsd-player namefile

You can find the image, as usual, here:
Get Started - Volumio

Enjoy and keep up the good work! Congrats to everyone involved, and please let me know if I can do any further!

Gday all,

Anyone know the pinout for the DSD for the RPi and the BBB?

Chuz,

Drew.
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.