As far as I know, TOSLINK SPDIF loses audio quality through jitter.
Thus, I would rather feed audio directly to a DAC than feed it to a DAC via (TOSLINK) SPDIF.
How much quality should I expect to lose via TOSLINK SPDIF?
Conclusion // Running an adaptive resampler(e.g., zita-a2j) on TOSLINK SPDIF Input is not a good idea. I'm going to explore pulseaudio over network and pulseaudio on top of netjack.
Thus, I would rather feed audio directly to a DAC than feed it to a DAC via (TOSLINK) SPDIF.
How much quality should I expect to lose via TOSLINK SPDIF?
Conclusion // Running an adaptive resampler(e.g., zita-a2j) on TOSLINK SPDIF Input is not a good idea. I'm going to explore pulseaudio over network and pulseaudio on top of netjack.
Last edited:
Toslink does indeed add more jitter, that's not in doubt. How bad that jitter sounds in practice to a large degree depends on the particular DAC you're using.
There is an upside to Toslink - it provides perfect isolation from common-mode noise. If your source is noisy (maybe a PC or small computer) then jitter may well be the lesser of two evils.
There is an upside to Toslink - it provides perfect isolation from common-mode noise. If your source is noisy (maybe a PC or small computer) then jitter may well be the lesser of two evils.
Perfect does not exist in the real world, thankfully it's also not required. I like to use the term blameless. Once a certain level of performance is achieved any improvements will not be identified in a level matched double blind listening test. Blameless performance in electronics is easy to achieve with good engineering and not a lot of money.
I'm sure the best solution to be free from jitter in the SPDIF interface is ASRC. I guess the ES9038 has internal ASRC for that purpose. The disadvantage of ASRC is a disability of synchronous sampling which is necessary for the rectangular window: exact FFT bin. You can't have a synchronous phase in the multi-system either.
How much degradation in audio quality should I expect in the following setup?
ALSA dmix --> SPDIF output of onboard soundcard --> SPDIF input of a DAC connected to Raspberry Pi 3 B+ --(zita-a2j resampling)--> jackd --(the same DAC on Raspberry Pi)--> a pair of speakers
zita-a2j resamples SPDIF input to jackd's clock.
Sampling rate is fixed to 48000 throughout the setup.
I suspect the combination of SPDIF and zita-a2j can degrade audio quality.
ALSA dmix --> SPDIF output of onboard soundcard --> SPDIF input of a DAC connected to Raspberry Pi 3 B+ --(zita-a2j resampling)--> jackd --(the same DAC on Raspberry Pi)--> a pair of speakers
zita-a2j resamples SPDIF input to jackd's clock.
Sampling rate is fixed to 48000 throughout the setup.
I suspect the combination of SPDIF and zita-a2j can degrade audio quality.
Last edited:
ASRC is before DA conversion. I do not understand - how does it affect FFT bin position? Thanks.
You are already using jackd - why don' t you send audio directly to RPi over network using netjack2 WalkThrough_User_NetJack2 * jackaudio/jackaudio.github.com Wiki * GitHub ?
I have no practical experience with the alsa jack plugin, cannot tell about the quality.
On the other hand - firefox does not support alsa anymore either. Did you try fairly recent pulseaudio with its network communication feature? The newer, the better, older versions had bugs in that area.
On the other hand - firefox does not support alsa anymore either. Did you try fairly recent pulseaudio with its network communication feature? The newer, the better, older versions had bugs in that area.
Pulseaudio itself has a lot of latency. I wouldn't use pulseaudio over network for videos that require lip sync.
I tried alsa jack plugin, and it is no good, either.
In my direct experiences, SPDIF is the best.
Every software that sends audio from ALSA to jack is deeply flawed.
My definite conclusion is that if I don't use SPDIF, a hardware audio mixer, or some other hardware, I may just attach a separate pair of speakers to Raspberry Pi.
I already tested a more complex setup involving SPDIF. It sounded fine, but I haven't measured actual signal degradation.
Firefox developers stopped supporting ALSA, but it still supports ALSA.
My firefox is built against ALSA on Gentoo Linux.
Firefox even supports JACK a bit, but its JACK support is still in its infancy.
For now, I just want to know how much degradation the combination of SPDIF and zita-a2j causes in audio.
I tried alsa jack plugin, and it is no good, either.
In my direct experiences, SPDIF is the best.
Every software that sends audio from ALSA to jack is deeply flawed.
My definite conclusion is that if I don't use SPDIF, a hardware audio mixer, or some other hardware, I may just attach a separate pair of speakers to Raspberry Pi.
I already tested a more complex setup involving SPDIF. It sounded fine, but I haven't measured actual signal degradation.
Firefox developers stopped supporting ALSA, but it still supports ALSA.
My firefox is built against ALSA on Gentoo Linux.
Firefox even supports JACK a bit, but its JACK support is still in its infancy.
For now, I just want to know how much degradation the combination of SPDIF and zita-a2j causes in audio.
Last edited:
As of alsa - jack - did you look at ALSA -> JACK Plug not working anymore / Multimedia and Games / Arch Linux Forums ?
SPDIF is a bitperfect digital channel, no problem with that. But the clocks are where the questions arise. In RPi - how will you handle the recovered clock by the SPDIF receiver? Will it time the I2S input bus (i.e. external master clock)? Does your audio device use the same clock from capture and playback (i.e. the recovered SPDIF clock), or does it time each direction separately?
Still a question - why not using a DAC with SPDIF input directly, without the RPi in between?
SPDIF is a bitperfect digital channel, no problem with that. But the clocks are where the questions arise. In RPi - how will you handle the recovered clock by the SPDIF receiver? Will it time the I2S input bus (i.e. external master clock)? Does your audio device use the same clock from capture and playback (i.e. the recovered SPDIF clock), or does it time each direction separately?
Still a question - why not using a DAC with SPDIF input directly, without the RPi in between?
I went way deeper than ALSA -> JACK Plug not working anymore / Multimedia and Games / Arch Linux Forums.
Directly routing audio from ALSA to JACK always results in xruns, pops, and crackles. I tried it for months before giving up and ended up inserting SPDIF between ALSA and JACK.
I was just looking for a way to share speakers between Raspberry Pi and my desktop computer without much hassle. If I didn't need to share speakers, I would just use ALSA dmix without anything else.
My suggested setup resamples SPDIF input to jackd's clock which is synchronized to DAC's clock. I don't know whether DAC has the same clock for SPDIF input and analogue output. Let's just assume that DAC has different clocks for SPDIF Input and analogue output.
Directly routing audio from ALSA to JACK always results in xruns, pops, and crackles. I tried it for months before giving up and ended up inserting SPDIF between ALSA and JACK.
I was just looking for a way to share speakers between Raspberry Pi and my desktop computer without much hassle. If I didn't need to share speakers, I would just use ALSA dmix without anything else.
My suggested setup resamples SPDIF input to jackd's clock which is synchronized to DAC's clock. I don't know whether DAC has the same clock for SPDIF input and analogue output. Let's just assume that DAC has different clocks for SPDIF Input and analogue output.
Last edited:
Please do not quote the entire post just above yours. This is explained in the RULES section. I have removed the over-quoting.I read Ian's I2S FIFO Project and Ian asynchronous I2S and S/PDIF FIFO KIT group buy.
I2S FIFO KIT costs 149 US dollars, and S/PDIF Interface Board costs $89 US dollars.
A pair of passive spakers and a chinese generic amplifier are cheaper than FIFO kit with SPDIF interface board.
It defeats the purpose of saving the money by sharing speakers between Raspberry Pi and my desktop computer.
It seems the simplest and minimalist solution is the best solution again.
I should just give a dedicated pair of speakers to Raspberry Pi and maybe use jack and netjack to share Raspberry Pi's speakers with remote JACK applications.
I2S FIFO KIT costs 149 US dollars, and S/PDIF Interface Board costs $89 US dollars.
A pair of passive spakers and a chinese generic amplifier are cheaper than FIFO kit with SPDIF interface board.
It defeats the purpose of saving the money by sharing speakers between Raspberry Pi and my desktop computer.
It seems the simplest and minimalist solution is the best solution again.
I should just give a dedicated pair of speakers to Raspberry Pi and maybe use jack and netjack to share Raspberry Pi's speakers with remote JACK applications.
Last edited:
At least I hope that we can agree on that any jitter added by toslink due to it's limited BW is compleatly removed if the incoming data is stored in a memory and klocked out "later" with an other (local) clock than the spdif one. Wrt tp bit faults, I did a test recently - I played a .wav file worth 10 minutes and stored it on the receiving computer. Using a file comparision tool, I could see that after taking away som initial headers etc, there where no bit faults. Zero.
In order to understand if toslink may work for you, you need to understand the whole clocking regime in your DAC. Not just the receiver chip, or the DAC chip - the system.
//
In order to understand if toslink may work for you, you need to understand the whole clocking regime in your DAC. Not just the receiver chip, or the DAC chip - the system.
//
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.