Re: [Alsa-user] Basic S/PDIF Recording

2010-10-27 Thread Clemens Ladisch
Paul Braman wrote: > S/PDIF data is being captured by a Wolfson WM8804 S/PDIF Digital > Interface Transceiver (or similar) and streamed over USB by a Texas > Instruments TAS1020B USB Streaming Controller. There are more > complicated issues regarding exactly what data is transmitted The WM8804 tra

Re: [Alsa-user] Basic S/PDIF Recording

2010-10-26 Thread Paul Braman
Clemens Ladish wrote: > > Almost all sound cards decode the S/PDIF stream; what you get are > plain samples (or compressed data pretending to be samples in case > of AC-3 or DTS).  The information in the other bits is usually > available with the control "IEC958 Capture Default". Hrmmm ... well, t

Re: [Alsa-user] Basic S/PDIF Recording

2010-10-26 Thread Clemens Ladisch
Paul Braman wrote: > Data is broken up on an S/PDIF stream into 64-bit frames grouped into > 192-frame blocks (1536-byte blocks). Assuming I can properly decode > all of the status bits in each frame, blah blah blah, I can end up > with either a PCM stream or, let's say, a compressed-audio stream >

Re: [Alsa-user] Basic S/PDIF Recording

2010-10-25 Thread Paul Braman
James Le Cuirot wrote: > > "Since compressed data is transmitted in place of PCM data, the bitrate > of the compressed stream must exactly match uncompressed stereo 16-bit > PCM bitrate. As a rule, compressed stream (even a multi-channel one) > having a lower bitrate, compressed stream must be padd

Re: [Alsa-user] Basic S/PDIF Recording

2010-10-25 Thread James Le Cuirot
On Mon, 25 Oct 2010 10:45:10 -0400 Paul Braman wrote: > Interesting, but I see a couple of idiological problems with this > approach. > > "dat" implies reading 32-bit frames at a rate of 48KHz. That's all > fine and good but an S/PDIF bitstream is going to be pumping data > faster than that rate

Re: [Alsa-user] Basic S/PDIF Recording

2010-10-25 Thread Paul Braman
James Le Cuirot wrote: > > If you want to try it for yourself, it's as simple as... > > arecord -Dspdif -f dat -t raw | spdifextract | ac3dec -6 Interesting, but I see a couple of idiological problems with this approach. "dat" implies reading 32-bit frames at a rate of 48KHz. That's all fine and

Re: [Alsa-user] Basic S/PDIF Recording

2010-10-25 Thread James Le Cuirot
On Mon, 25 Oct 2010 15:18:03 +0100 James Le Cuirot wrote: > Apparently a PLL is needed to synchronise the clock frequency but I > haven't been able to determine whether any sound cards out there have > these at all. I've heard of some Creative cards having on-board AC3 > decoders but I think this

Re: [Alsa-user] Basic S/PDIF Recording

2010-10-25 Thread James Le Cuirot
On Mon, 25 Oct 2010 09:50:19 -0400 Paul Braman wrote: > I'll assume I want to read in blocks of 1536 bytes-at-a-time as long > as ALSA is properly synchronizing to the S/PDIF frame and giving me > aligned blocks. Is this an assumption I can make? Probably not. I recently thought I would be cleve

[Alsa-user] Basic S/PDIF Recording

2010-10-25 Thread Paul Braman
Let me first describe the concepts I understand and then I might be able to ask some questions that make sense. Data is broken up on an S/PDIF stream into 64-bit frames grouped into 192-frame blocks (1536-byte blocks). Assuming I can properly decode all of the status bits in each frame, blah blah