Raspberry Pi and DACs / Computer Science / Forums

Forums

4hv.org :: Forums :: Computer Science

« Previous topic | Next topic »

Raspberry Pi and DACs

previous 1 2 3 4

Move Thread

LAN_403

Steve Conner

Mon Feb 11 2013, 12:28PM

Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706

Yeah, but the network chip was also the USB hub. :( The Broadcom SOC only has one USB port.

Update: I have hours of glitch-free listening at 16/44.1 and 24/48 now, and 24/96 seems glitch-free too. At 24/192 I get a pop every few minutes. I'm thinking of getting a Model A to see if removing a USB hub from the chain helps.

Carbon_Rod

Tue Feb 12 2013, 01:23AM

Registered Member #65 Joined: Thu Feb 09 2006, 06:43AM
Location:
Posts: 1155

Some codec + DAC chips have a buffer that automatically rate-limits the playback.

Depending on your overclock settings (far more stable at 850MHz with no over-voltage)
The USB lag issues may still be jamming up the works:

Also, some distros have a fudged clock backup that runs every few minutes on a cron job.

The 512MB B version definitely performs better as the i/o write bottleneck is usually SDHC card related, and the low-swap mode setting forces most so libs into resident ram. The 256MB version B we tested also >seems< to have slightly less CPU performance running identical OSs.

Steve Conner

Tue Feb 12 2013, 12:07PM

Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706

I'm not using any overclock. I disabled the ondemand governor so it runs at the standard clock rate (700MHz?) all the time. Are you saying that an overclock to 850MHz would make it more stable than this? Or do you mean it's more stable than a more radical overclock would be?

Also, what's a "fudged clock backup", how would I go about looking for it? Something to do with the Pi's lack of a RTC?

When my system is playing, it hardly seems to access the SD card. The activity light blinks once every few seconds. I've considered trying to get it all to run from a ramfs, to get SD card DMA transfers out of the picture, but I'm not sure where to start.

Carbon_Rod

Wed Feb 13 2013, 03:11AM

Registered Member #65 Joined: Thu Feb 09 2006, 06:43AM
Location:
Posts: 1155

A mode 6 no over voltage on core setting ensures the SD card i/o will behave better, and reduces the USB stack latency which can cause a reset glitch.

Note, the read speeds are far faster than block writes on most of these cards.

In general, one can use the auto generated temp path that overflows to a swap file, but it is less predictable.
mount -t tmpfs tmp /mnt/tmp

...or preallocate an area of RAM to fit two flac/mp3 tracks
mount -t ramfs ram /mnt/ram

That later fixed area should make the buffer more reliable if intermittently fetching a file in one thread while playing another already ram cached file.

=)
Rod

Steve Conner

Wed Feb 13 2013, 11:18AM

Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706

I'll try winding it up to 850MHz and report back! :)

I'm using MPD as my player. I don't know how I would make it cache things in a RAM disk. I suspect it already caches quite a lot of audio in ordinary RAM. If that got swapped out, things could indeed get nasty.

I'm wondering whether I can get the entire OS to run out of a ramfs, like our Windows CE platform does at work. When you power it up, the bootloader copies the whole OS image from flash into RAM, and executes it from there. The flash is never touched after that, except for a small partition that I use as a FAT formatted drive to store field-upgradeable code and calibration data.

Raspbian is far bigger than our 12MB image, but then again the Pi has lots more RAM than our embedded system.

Carbon_Rod

Fri Feb 15 2013, 08:37AM

Registered Member #65 Joined: Thu Feb 09 2006, 06:43AM
Location:
Posts: 1155

Just about every LiveCD uses the squashfs + chroot, but it depends how much room you need.

Some people who only need the bare kernel plus a few programs will simply create a larger <100MB custom initramfs image that loads at boot time. Quite common for PXE booting anti-virus software for example.

Conundrum

Sun Feb 17 2013, 08:50AM

Registered Member #96 Joined: Thu Feb 09 2006, 05:37PM
Location: CI, Earth
Posts: 4061

What about bypassing the SD altogether and raw booting directly from the pins the network SoC uses with an external microSD reader.. ?
Ought to work maybe?

Hon1nbo

Thu Mar 12 2015, 03:36PM

Registered Member #902 Joined: Sun Jul 15 2007, 08:17PM
Location: North Texas
Posts: 1040

(reviving the dead, both this post and my account activity!)

Turns out, they now make an add-on for the Pi that has some good Wolfson DACs on it. IT will max out the Pi's performance if you don't do out of the box tweaks, but it works.

This is actually similar to the original DAC back when I planned the project. I have since had little time to do much with it, along with many other projects outside of classes.
I currently have an iBasso DX90 (was a very generous gift for my graduation), but I am planning to test this combo out as well for some other uses... maybe make a 3D printed enclosure, include a small OLED screen, and package it all. (as I grab my 3D mouse for CAD)
Cheers,

-Jim

previous 1 2 3 4

Moderator(s): Chris Russell, Noelle, Alex, Tesladownunder, Dave Marshall, Dave Billington, Bjørn, Steve Conner, Wolfram, Kizmo, Mads Barnkob