[tschanrm]

Don't know if this has ever been discussed before, but there is an old program called Mpegspdif (http://www.cs.tut.fi/~ik/mpegspdif.html for foobar. It sends the MP3 file over the s/pdif link for the receiver's DSP chip to decode it. Why would I want to decode the MP3 at the receiver? Easy, you remove all jitter/connection related problems associated with the s/pdif line.

Well, I tried this, and it works! Limitations are that it needs to be 44.1khz mp3 file, and the sound card can't resample. Receivers which can decode MP3 that I know of are:

Panasonic's XR-10
harman/kardon AVR 3500

I'll try to post more on this later. Look up your receiver's DSP chip and find out if it can decode MP3!

 

[Asmo]

Pointless.

 

[tschanrm]

Please explain why this program is pointless? I think this is great program if anyone has their music encoded in MP3. You no longer have to worry about your s/pdif connection, or spending money on expensive digital cables.

 

[grawk]

I fail to see the benefit of having your receiver use a dsp to decode your mp3s when your source probably has better circuitry or software for it...

 

[tschanrm]

Quote:

I fail to see the benefit of having your receiver use a dsp to decode your mp3s when your source probably has better circuitry or software for it...

Well, like I just said, you don't have to worry about your s/pdif connection at all. You would essentially have no jitter in the signal because the s/pdif interface is acting as a bitstream (jitter would only be related to the clock in the receiver). You can use whatever type of cable you want; the cheapest cable or the most expensive cable will still have the exact same audio quality by having the receiver decode the signal. You could run a 50' length of coax digital cable to my receiver and not worry about loss of audio fidelity. My receiver is in another room, so this seems like a definite advantage to me, as I don't have to spend money on a squeezebox now.

Plus by having the receiver decode ensures that you have a bit-perfect signal.

And AFAIK hardware decoders are every bit as good as a software decoders. Hope this helps explain.

 

[jefemeister]

interesting. I think a similar system could become more commonplace as more and more DACs and receivers get onboard compressed audio capability. It is unfortunate that the mp3 has to be limited to 44.1, but I believe that most are anyway.

 

[thomaspf]

@tschanrm

That is unfortunately not like almost all receivers work. Even for encoded content the converison clock is derived from the input signal. Since there is no feedback the playback speed must be in one way or the other slaved to the incoming data rate or you get over/under-runs.

This is also true for DD/DTS signals.

So in summary you either have a DAC that does a good job on dejittering (hoepfully without an ASRC) for all incoming streams or you don't.

Cheers

Thomas

 

[tschanrm]

Thomas,

Well, I guess I don't understand DD/DTS stream that well, or IEC-61937 for that matter to refute what you say, so I'll just beleive you.

Why would this person write this program then if there seems to be no advantange in doing so? Fundamental exercise maybe?

 

[Tim D]

Neat find.

Also I'm really not sure if it is clocked from the soundcard or not...the program description and code seems to say it pads the mp3 data just so it goes over the digital link. It says that it doesn't work if cards resample to 48khz, etc so I am thinking that is basically because it is no longer bit-perfect and thus corrupting the actual data when spit out.

If the actual Mp3 data goes over the link that it should be the receiver that is master clock.

However keep in mind that the analog quality if not jitter of a high quality soundcard can possibly still be better than a very 'busy' consumer receiver (i.e. one that has a billion inputs/outputs, DACs, DSP's, decoders, speaker outputs, radio tuner, video circuitry, kitchen sink).

 

[thomaspf]

How can the receiver be the master clock with a S/PDIF connection that is only one way?

What if the computer keeps sending data faster than that master clock plays back the content. What if it is slower?

Encoded content still requires slaving the clock in the receiver in a simple S/PDIF setup.

Cheers

Thomas

 

[Glassman]

thomas is of course absolutely right here.. doesn't matter at all what data are being sent over S/PDIF, only that it is S/PDIF and thus unidirectional master-slave link.. the receiving side must lock on the input unless you want to loose data..

 

[Tim D]

But is it electrical/data jitter as opposed to audio domain jitter?

I can see reasons why DD/DTS is slaved to source if there is video playback to sync to. But for Mp3 I don't see any reason to slave to source. Guess it depends on implementation. Also when I mention master clock, I don't mean the relationship between the SPDIF data transfer, but what clock is used after the decoding of the mp3. *shrug*

 

[thomaspf]

But for Mp3 I don't see any reason to slave to source. Guess it depends on implementation.

Sorry, but that just is not so. Since you can not signal back to the source to speed up or slow down you need to estimate the average incoming rate and follow to clock of the incoming stream in the receiver.

There can be no indepdendent clock in the receiver.

Cheers

Thomas