I want to receive bit-perfect non-PCM (e.g. Dolby Digital/DTS) toslink input, process it with fairly low latency, and output a stereo result over toslink. I understand that I cannot expect this to work with the Dac+ DSP, since it resamples the input. Can I expect it to work with the Digi+ I/O?
EDIT: Just to clarify, I understand that the board won't decode a Dolby bitstream for me- I just need to know whether I can losslessly receive it so I can decode it in software.
While it might work, it has never been tested.
Best regards,
Daniel
Thank you but, just for the avoidance of doubt, can you confirm that the I/O can receive 16-bit 48K without resampling or otherwise distorting the data in any way? I understand that the DAC+DSP does resample and therefore will not work, can you confirm this does not apply to the Digi+ I/O?
The Digi+ does not resample anything as it does not have any hardware to do this.
Best regards,
Daniel
I have same needs, but so far I haven't succeed. By principle, it should be possible using alsa driver and snd_pcm_format_iec958_subframe_le. Each subrame is 32-bit and contains payload bits, audio block syncronization and status word (just google iec958 specification).
The problem is that there is not that much information how to initialize alsa driver for this and is it even supported. I have managed to receive 16-bit raw-data when input is normal pcm, and some data which looks like compressed audio stream with lots of zero padding between payload. However, I haven't been able to receive actual iec958 subframe, which I would need to syncronize audio blocks and know which data is just padding.
As I mentioned in my post I made a week ago, I'm looking possibility to fix the driver if it's broken or maybe use i2S directly to receive the data. It is also possible that current driver works ok when initialized corretly.
Here is the piece of code I use. It is not working as I expect, but you get the idea. I'm not sure should what channel count I should use, or should I use interleaved attribute. I have tried other options with no success. For some reason, iec958 subframe format works reliably only with synchronous read. Normal audio can be read reliably with async params too.
int stat = snd_pcm_open(&handle, "hw:CARD=sndrpihifiberry,DEV=0", SND_PCM_STREAM_CAPTURE, 0);
if (stat < 0)
{
qDebug()<<"unable to open pcm device: "<<snd_strerror(stat);
return false;
}
snd_pcm_hw_params_t *params;
snd_pcm_hw_params_alloca(¶ms);
snd_pcm_hw_params_any(handle, params);
snd_pcm_hw_params_set_access(handle, params, SND_PCM_ACCESS_RW_INTERLEAVED);
snd_pcm_hw_params_set_format(handle, params, SND_PCM_FORMAT_IEC958_SUBFRAME_LE);
snd_pcm_hw_params_set_channels(handle, params, m_channelCount);
snd_pcm_hw_params_set_rate_near(handle, params, &samplerate, &dir);
snd_pcm_uframes_t frames = m_framesPerBuff;
snd_pcm_hw_params_set_period_size_near(handle, params, &frames, &dir);
stat = snd_pcm_hw_params(handle, params);
if stat < 0)
{
qDebug()<<"unable to set hw parameters: "<<snd_strerror(rc);
return false;
}
snd_pcm_hw_params_get_period_size(params, &frames, &dir);
qDebug()<<"Init frames="<<frames<<" dir="<<dir;
if(handle)
{
for(int i=0;i<1000;i++)
{
stat = snd_pcm_readi(handle, rawbuffer.data(), frames);
qDebug()<<" len="<<frames<<" stat="<<stat;
stfile.write(rawbuffer.data(),stat*4);
}
}
@Tero Piispala:
In my case I'm trying to decode Dolby/DTS bitstreams in software. I currently have a working test implementation using a cheap USB CM6206-based device, and the 16-bit stream is enough- I don't need the full subframe information.
If your intent is to do the same, some pointers: You can detect the end of padding by looking for a iec60958 header (eight zero bytes followed by F8, 72, 4E, 1F). The next two bytes (big endian) indicate the type of compressed stream, and the two after that are the length in bits of the Dolby/DTS frame. Read that many (/8) bytes, pass them to your decoder library, and then start looking for the next iec60958 header.
Apparently it's also possible to have a non-iec60958-wrapped Dolby/DTS stream, in which case you'll just need to look for the relevant syncwords instead. A fully robust solution would deal with both, but all my sources do use iec60958 so I went the lazy route and only supported that.
@Tero Piispala:
To do what I described above, you don't need to open it with any special flags- 2ch 48k 16bit interleaved is enough. (Actually for testing with Portaudio on Windows I did need to pass some extra flags to stop WASAPI running some DSP stuff, but that shouldn't be a concern on the pi).
Apologies if I misunderstood you and you do need subframe data.
Thanks for the information. It might get handy. I'm also planning to decode the stream with software and I already have a working code for that. I thought the raw sub-frame data was the best way to synchronize into audio blocks, but the header you mentioned will also work and I probably try it.
I also used Portaudio in my first tests, but I had problems with latency and synchronization. I need 8-channel uncompressed output, so I have to use hdmi. Apparently in Raspbian, Portaudio can't synchronize streams between different devices which have different clock-base. Streams play for a while and then hangs up or suffer from scratching noise. Sometimes latency goes very long. With Alsa and custom synchronization, I don't have that problem. Latency is quite small (less than 30ms)
Could that board enable DTS to Dolby conversion with negligible latency?
How hard can it be to put all that together? Which distribution do you recommend? Do we have the software package for DTS decoding and Dolby encoding? FFmpeg maybe?
I'm new to Pi put got 20 years of software engineering behind me.
I'm trying to setup a DD/DTS decoder to PCM out on HDMI. My intent was a digital mixer before sending to my Bose system.
@Jonathan:
> Apparently it's also possible to have a non-iec60958-wrapped Dolby/DTS stream, in which case you'll just need to look for the relevant syncwords instead. A fully robust solution would deal with both, but all my sources do use iec60958 so I went the lazy route and only supported that.
I've implemented just that: https://github.com/Shulyaka/pareceive