This seems like an interesting project. I'm tempted to give it a try and see how well it works.
Right now I've found the only way I can get digital sound from this is to use an HDMI splitter, or use the TOSLINK out from a TV supporting audio over HDMI.
Now exactly ideal.
Would I be able to use something like a Behringer UCA202 in order to get a digital out?
Alternativly there is I2C which I totally unfamiliar with.
Would it be possible to hook the I2C from the RasbPi to a DCX2496? If so how easy is it to do?
Thanks
Right now I've found the only way I can get digital sound from this is to use an HDMI splitter, or use the TOSLINK out from a TV supporting audio over HDMI.
Now exactly ideal.
Would I be able to use something like a Behringer UCA202 in order to get a digital out?
Alternativly there is I2C which I totally unfamiliar with.
Would it be possible to hook the I2C from the RasbPi to a DCX2496? If so how easy is it to do?
Thanks
I have a temporary solution in place currently whilst I plot my next move, it might be of interest to you: I'm using a cheap USB external soundcard, namely the Creative Soundblaster Live card.
It's completely plug and play with my Raspian distro - all you need is a USB cable, and then of course your choice of cable into the DAC.
Actually, you don't even need cables - I've just about been able to couple my RPi, soundcard, and DAC together with adapters. (My theory of course is that taking the cables out of the equation is a good thing, which logic tells me is true ... but I'm sure somebody will be along soon to correct me
)Good luck there. I have some simple projects running using the GPIO, but I imagine it would be very challenging to get I2C/S working efficiently.
I think there is a thread on this elsewhere, IIRC. Anyway, I'm sure the more experienced members of this forum will guide you better than I can in this domain.
There is no reason a pure playback without any resampling should take more than that. Plus MPD uses quite large alsa buffers which makes it reduce CPU load too.
In complete opposite direction is the nrpacks=1 setup which forces the USB controller throw IRQ every 1ms (at least on UHCI-compatible machines) which must be services by the CPU.
Recent alsa patches remove this setup alltogether, calculating appropriate nrpacks value based on requested buffer/period sizes Re: [alsa-devel] Buffer size for ALSA USB PCM audio -- Linux USB
That's really interesting.
A few weeks ago I had added
options snd-usb-audio nrpacks=1
to my alsa-base.conf file to cure a logging problem in the mpd code, and so I am running in this mode ... but we are not seeing the high CPU load.
The recent patch which has removed the aforementioned static int from headers and source files can't be on my system, since I haven't performed any package updates in a long time.
What gives? Is something not working correctly?
FWIW, I only ever play 44.1 PCM (.wav) files, so I'm not sure I understand what need there might be for resampling in my context. (Although this area is admittedly beyond my knowledge for the moment.)
Here is a nice function to list parameters of running loaded modules. https://wiki.archlinux.org/index.php/Kernel_modules#Bash_function_to_list_module_parameters
Just copy the code into terminal window and run aa_mod_parameters . That way you can check your loaded snd-usb-audio module parameters.
Just copy the code into terminal window and run aa_mod_parameters . That way you can check your loaded snd-usb-audio module parameters.
Have you seen the RPi-DAC by tjaekel?
He use the Raspberry Pi P5 connector for direct I2S connection to the DAC board.
I actually got one of his borads right here for testing, just haven't had the time to order parts yet.
I'm not that good with Linux, but hopefully I'll be able to recompile the kernel following his instructions once the DAC is finished
There's a new alternative for a small form-factor Linux board - the Intel Galileo Arduino form-factor board with a 400 MHz ultralow-power Pentium-class IA32 core:
Introducing the Galileo Development Board
It has GPIOs as well as a USB client (slave) interface, so in principle it should be possile to build a USB to I2S converter with it. A DAC board (say ES9023-based) could be piggy-backed on the GPIO connector, and voila! - there's potentially a 24/192 USB DAC platform in the making.
Introducing the Galileo Development Board
It has GPIOs as well as a USB client (slave) interface, so in principle it should be possile to build a USB to I2S converter with it. A DAC board (say ES9023-based) could be piggy-backed on the GPIO connector, and voila! - there's potentially a 24/192 USB DAC platform in the making.
Hi Heffa,
I can help you. Some comments are on web site (incl. links), otherwise Google for Kaolo's blog or check out this link:
koalo's blog: I2S Audio Support for Raspberry Pi
BTW:
You just need to get Kaolo's Rasbian kernel, it has several drivers already. I took the ESS9018 driver source and have modified just very few code lines (mainly just a constant for the I2S config and mode).
Even all the module names, drivers etc. are still for ESS9018 - it works fine for PCM1794A.
Just the fact: the change in source code configures 24bit I2S on RPi and let it send via I2S 24bit samples. But the audio format is still 16bit: the 16 bits are send as upper bits, the lowest 8 bits are filled with constant values (I would guess 0, or the LSB of the 16bit word). It works, not a real 24bit format which is much harder to implement (DMA and handling of 3-byte word chunks, so I use all the 2-byte supported DMA driver features).
It results in: if you use aplay (ALSA) or mplayer - you have to use still 16bit PCM (WAV) files, not 24bit. (if you use aplay on command line).
But the good news: if you use VLC on XWindow GUI: it is smart and will take any format, even 24bit or 32bit. It will down-sample to the next possible format, here 24bit to 16bit will be done by VLC.
You can do all on the RPi itself (get repository, compile and patch the kernel).
But be patient: it takes more then 8 hours for the first procedure (later it is faster on incremental C-code changes).
And: I got my SD card crashed almost every time. It writes so much to SD card that my file system was always corrupted. It needs a careful and frequent image backup after some compile steps just to make sure not to start over (and to lose another day).
BTW:
If you want to try RPi-DAC (or T-DAC) without RPi, as a standalone USB sound card - I am working on an USB front end: idea: take a STM32F4DISCOVERY.
It costs just 15 USD (entire board is cheaper as the SoC itself on it). And it has already an I2S DAC + Class-D headphone chip. I want to break out on header the I2S and feed the RPi-DAC from it.
It needs just to create the Cortex-M4 firmware with USB audio streaming class (I have it already working on another STM32F4).
Best regards
Torsten
I can help you. Some comments are on web site (incl. links), otherwise Google for Kaolo's blog or check out this link:
koalo's blog: I2S Audio Support for Raspberry Pi
BTW:
You just need to get Kaolo's Rasbian kernel, it has several drivers already. I took the ESS9018 driver source and have modified just very few code lines (mainly just a constant for the I2S config and mode).
Even all the module names, drivers etc. are still for ESS9018 - it works fine for PCM1794A.
Just the fact: the change in source code configures 24bit I2S on RPi and let it send via I2S 24bit samples. But the audio format is still 16bit: the 16 bits are send as upper bits, the lowest 8 bits are filled with constant values (I would guess 0, or the LSB of the 16bit word). It works, not a real 24bit format which is much harder to implement (DMA and handling of 3-byte word chunks, so I use all the 2-byte supported DMA driver features).
It results in: if you use aplay (ALSA) or mplayer - you have to use still 16bit PCM (WAV) files, not 24bit. (if you use aplay on command line).
But the good news: if you use VLC on XWindow GUI: it is smart and will take any format, even 24bit or 32bit. It will down-sample to the next possible format, here 24bit to 16bit will be done by VLC.
You can do all on the RPi itself (get repository, compile and patch the kernel).
But be patient: it takes more then 8 hours for the first procedure (later it is faster on incremental C-code changes).
And: I got my SD card crashed almost every time. It writes so much to SD card that my file system was always corrupted. It needs a careful and frequent image backup after some compile steps just to make sure not to start over (and to lose another day).
BTW:
If you want to try RPi-DAC (or T-DAC) without RPi, as a standalone USB sound card - I am working on an USB front end: idea: take a STM32F4DISCOVERY.
It costs just 15 USD (entire board is cheaper as the SoC itself on it). And it has already an I2S DAC + Class-D headphone chip. I want to break out on header the I2S and feed the RPi-DAC from it.
It needs just to create the Cortex-M4 firmware with USB audio streaming class (I have it already working on another STM32F4).
Best regards
Torsten
Have you seen the RPi-DAC by tjaekel?
He use the Raspberry Pi P5 connector for direct I2S connection to the DAC board.
I actually got one of his borads right here for testing, just haven't had the time to order parts yet.
I'm not that good with Linux, but hopefully I'll be able to recompile the kernel following his instructions once the DAC is finished
You can configure a plug plugin and limit its slave device specifically to 16bits in .asoundrc. That way your alsa device will accept any format and will output always 16bits downstream (i.e. hw:CARD). The plug plugin will handle the necessary conversion automatically.
Code:
pcm.always16 {
type plug
slave {
pcm hw:Intel
format S16_LE
}
}Note the conversion to 16 bits:
Code:
aplay -v -D always16 192-24.wav
Playing WAVE '192-24.wav' : Signed 24 bit Little Endian in 3bytes, Rate 192000 Hz, Stereo
Plug PCM: Linear conversion PCM (S16_LE)
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S24_3LE
subformat : STD
channels : 2
rate : 192000
exact rate : 192000 (192000/1)
msbits : 24
buffer_size : 96000
period_size : 24000
period_time : 125000
tstamp_mode : NONE
period_step : 1
avail_min : 24000
period_event : 0
start_threshold : 96000
stop_threshold : 96000
silence_threshold: 0
silence_size : 0
boundary : 1572864000
Slave: Hardware PCM card 0 'HDA Intel' device 0 subdevice 0
Its setup is:
stream : PLAYBACK
access : MMAP_INTERLEAVED
format : S16_LE
subformat : STD
channels : 2
rate : 192000
exact rate : 192000 (192000/1)
msbits : 16
buffer_size : 96000
period_size : 24000
period_time : 125000
tstamp_mode : NONE
period_step : 1
avail_min : 24000
period_event : 0
start_threshold : 96000
stop_threshold : 96000
silence_threshold: 0
silence_size : 0
boundary : 1572864000
appl_ptr : 0
hw_ptr : 0How difficult would it be to convert the I2S to S/PDIF Coax?
Would that allow for dts/ac3 passthrough?
BTW, fixed the network related dropouts.
It turned out i had to remove smsc95xx.turbo_mode=N.
Sound plays fine now using HDMI.
Might do some comparison against the infrasonic quartet soundcard in the main system later.
Since the ARM core, as I understand it, isn't too good at handling low latency interrupts, they are better serviced by the GPU.
This should give the HDMI output using the GPU a theoretical advantage on the RPi, shouldnt it.
Does anybody know what a recommended memory splitting would be for (headless) HDMI audio playback?
Would that allow for dts/ac3 passthrough?
BTW, fixed the network related dropouts.
It turned out i had to remove smsc95xx.turbo_mode=N.
Sound plays fine now using HDMI.
Might do some comparison against the infrasonic quartet soundcard in the main system later.
Since the ARM core, as I understand it, isn't too good at handling low latency interrupts, they are better serviced by the GPU.
This should give the HDMI output using the GPU a theoretical advantage on the RPi, shouldnt it.
Does anybody know what a recommended memory splitting would be for (headless) HDMI audio playback?
A couple of questions, related to the OP but more to do with the method of alsa replay:
1) MPD has a volume control which seems to be set to around 80% by default. Is it possible to disable this volume control? Or, if not, what is the volume setting which is the equivalent to playing the 'raw PCM'? (My guess is the 100% setting would do the job, based on my experience of coding with the win32 audio API's.)
2) From a sonic perspective only, are there any benefits of using aplay over MPD?
Apologies if these questions are a bit simple, but I thought I would ask before exploring the code. (I'm away from home for a week so have little access to the internet and no access to my RPi).
1) MPD has a volume control which seems to be set to around 80% by default. Is it possible to disable this volume control? Or, if not, what is the volume setting which is the equivalent to playing the 'raw PCM'? (My guess is the 100% setting would do the job, based on my experience of coding with the win32 audio API's.)
2) From a sonic perspective only, are there any benefits of using aplay over MPD?
Apologies if these questions are a bit simple, but I thought I would ask before exploring the code. (I'm away from home for a week so have little access to the internet and no access to my RPi).
The actual conversion is not difficult, it just takes a specialized chip - SPDIF transmitter. However, for reliable proper operation you need a way to provide control information - e.g. setting SPDIF preamble. At least audio/non-audio bit for AC3 streams - look at 'IEC958 Playback Default' control for any card with spdif output (most integrated ones on MB) listed in "amixer contents". Value of that control is operated by video players for AC3 streams
Public Git Hosting - mplayer.git/blob - libao2/ao_alsa.c
git.alsa-project.org Git - alsa-lib.git/blob - src/conf/cards/ICE1724.conf
iecset(1): Set/dump IEC958 status bits - Linux man page
1. Why serving interrupts with low-latency requirement for audio playback?
2. The IRQs will be processed by the CPU, whether they are thrown by the USB controller (USB cards) or the ASoC audio controller (built-in soundcard/analog-HDMI output).
MPD uses either the volume control elements provided by your soundcard (for available controls see alsamixer -c CARDNAME), or its internal volume control feature. All is configured by mpd params mixer_type, mixer_device, mixer_control, mixer_index - see man mpd.conf.
Provided your chain is configured to do no resampling, it is bit-perfect. If so, a sonic difference has never been published to exist in a credible blind listening test.
I would keep buffer_time in mpd as large as possible to minimize risks of xruns. The default of 500ms is a reasonable value.
Last edited:
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.