• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 32 subscribers
  • Views 1842 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

6 channels I2S source for TAS3308

Vladimir Timohin
Prodigy 210 points

Does exist any decoders for decoding S/PDIF 5.1 into synchronous 5.1 I2S ?



With best regards, Vladimir.

  • 0
    TI__Expert 4160 points

    Vladimir,

    IEC-60958 discusses how to use SPDIF to transfer 2.0 PCM uncompressed.  Basically, SPDIF can transfer 2 channels of up-to 24-bit audio at a clock rate of 64x the sample rate.

    IEC-61937 discusses how to transport AC3, DTS, WMA, AAC, etc. over SPDIF. 

    This is the only way I know to move '5.1 audio' over SPDIF in a reasonable manner, since SPDIF has insufficient bandwidth to transfer uncompressed 5.1 PCM using a standard uncompressed format.  [If you want to transfer 5.1 48kHz, then if  you ran your SPDIF-like AES/EBU at 192kHz, you would have sufficient bandwidth, but you would have to unpack the received samples somehow - you would have to use custom packing on the source side and custom unpacking on the receiver, and have to use 192kHz AES/EBU, which not many devices support.]

    Apparently, you are asking if decoders exist to decode AC3, DTS, WMA, AAC.

    The answer is "yes, such decoders exist", but few (if any) are free, may require a royalty license, may require more MIPs than you have available, might not be ported to your device, etc.

    Frank

  • 0 in reply to Frank Minich
    Intellectual 270 points

    Been wondering why there isn't a 5.1@48kHz linear PCM  framing specification for S/PDIF. Guess it would be possible using the extra bits.

    However, these days you could also use HDMI for multi-channel PCM transfer though I don't know what kind of transmitter/receiver chips support it.

    Well, google found these chips (from NXP this time):

    http://www.nxp.com/#/pip/pip=[pip=TDA19977A_TDA19977B,pfp=55186]|pp=[t=pip,i=TDA19977A_TDA19977B]

     

     

     

  • 0 in reply to Mikko Helin
    TI__Expert 4160 points

    Mikko,

    There are only a maximum of 64 bit times/sample instant using SPDIF - actually fewer, since some of the bit times are used for framing.

    Would 8-bit audio be sufficient?  If so, then you could take the 24 bits for Left and 24 bits for Right and reallocate.

    But, again, you would need to write both sides, and you would have a non-standard interface.

    IEC61937 works over SPDIF because, due to compression, it is possible to insert some identification information along with the encoded content so that a receiver capable of handling IEC61937 can determine that the content is not simple PCM.  That becomes harder when you need to use all 24*2 bits for audio.

    Frank

  • 0 in reply to Frank Minich
    Intellectual 270 points

    Frank,

    Easiest way would be using software decoding. If your application is something like DD 7.1 or some other multichannel audio where the source is PC you could  write some wrapper driver which converts max. 7.1 audio stream of  24 bits@48 kHz to interleaved "stereo" 24bit @192 kHz and sends it over S/PDIF to receiver. In this case you don't know in receiver end which channel is which. So you could just reserve the 2 LSB's of each 24-bit sample pair (A&B channels) for coding the channel number and still have 132 dB dynamic range left (guess exceeding the DR of all current DAC's). Using something like FPGA for implementation (of S/PDIF coding) on both ends you could use the extra bits to mark the first sample.

    Edit: Actually you need just two bits per stereo sample (= one bit per sample) for coding the frame number from 0-3, so the DR would be 23*6 = 138 after all.

  • 0 in reply to Mikko Helin
    TI__Expert 4160 points

    Mikko,

    Sure, you can do it.  I've never actually seen SPDIF above 96kHz, but have seen/used AES/EBU at 192kHz.

    Alternatively, you _could_ use 1394.