• 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.

Jump to Latest
#603
#604
glt said:
Reports say that at 352/384K sample rate, it skips. Either the processor is running out of juice or some other issue...
Click to expand...

You can check this using vmstat and top. Unless the player is particularly badly optimized, there is no reason for it to skip on 384k stereo and to not skip on 8 channel 96k HDMI playback... so if 8 channel works and 384k doesn't, there is probably something to tune somewhere to make it work.

If you're using realtime sample rate conversion, it's a different story...

On my desktop PC I run the player with realtime priority like this :

sudo schedtool -R -p 1 -e alsaplayer -d "hw:CARD=DAC,DEV=0"

The kernel isn't a realtime one (just a vanilla desktop kernel). The -ck kernels have an Isochronous (SCHED_ISO) priority level which is more practical :

Unique to -ck this is a scheduling policy designed for pseudo-realttime scheduling without requiring superuser privileges (unlike SCHED_RR and SCHED_FIFO). When scheduled SCHED_ISO, a task can receive very low latency scheduling, and can take the full cpu like SCHED_RR, but unlike the realtime tasks they cannot starve the machine as an upper limit to their cpu usage is specified in a tunable (see below). It is designed for realtime like behaviour without risk to hanging for programs not really coded safely enough to be run realtime such as ordinary audio and video playback software. SCHED_ISO does not take a realtime priority, but nice levels like other normal tasks, although the nice value is largely ignored except when the task uses more than its cpu limit.
Click to expand...
 
#609
Beta board preview

Here is what I have right now for a layout.

I have uFL to MCK,BCK,D1,D2 (B3SE mapped)

I added teleporter header.

I have a header that exposes most of the raw signals (I will document that later)

There is power that can optionally supply or be supplied by the BBB via L1

Header for direct connection to B3 or B3 SE

I2C header on dedicated I2C channel.

I made provision for the big Crystek, or smaller less expensive clocks. They are offset to better allow the use of two separate paste masks for production.

Feedback welcome.

Cheers!
Russ
 

Attachments

  • cape.jpg
    cape.jpg
    239.1 KB · Views: 787
#612
Its got everything I could want except an insertion point for a Trident or similar regulator for the clocks... but I'd rather get a Biotic sooner than wait for that, especially given your comment a few posts back.

BTW, SPDIF input gone? Not an issue for me, just curious.

Greg in Mississippi
 
#613
Power regulation?

Hi Russ,

Another question for your beta design: when you say,

"There is power that can optionally supply or be supplied by the BBB via L1"

do you mean that there will be regulation of the input power by the cape? BBBs come with an input pin for a 5 V supply. If I connect the supply to the cape instead of the BBB will it be regulated?

I am looking forward to this exciting development. Thanks for your fine work.

- David
 
#615
I can only add to the chorus of "Yay's" - it'll do what I want but then I am a simple man of dubious taste 🙂

Spec the best clocks you can Russ and put the first batch on order - I don't think there'll be any shortage of buyers. I assume this is going to be a pre-built board with all SMT?
 
#620
A provision to use trident shunt regulators for the board clocks and ICs would be perfect!

Will there be isolated and unisolated output on the board?
What kind of isolators will you use?

Will this be a readily soldered board or a kit?

I can't wait to get my hands on one of these!

Regards,
 
You must log in or register to reply here.
Top Bottom