The way I understand it the DSP re-samples the SPDIF/TV clock to the clock provided by the RPI. The RPI clock is still different than that of my HDMI receiver. What I need is a way to modify the RPI clock so that I can adjust it to be closer to my receiver so that all of the required re sampling gets done in the DSP.
Edit: An assumption I've made here is that you cannot get audio from the DSP into the RPI without using the RPI clock. I'll ask if that's true when I post the question on Hifiberry forums. Thanks for the thought!
Edit: An assumption I've made here is that you cannot get audio from the DSP into the RPI without using the RPI clock. I'll ask if that's true when I post the question on Hifiberry forums. Thanks for the thought!
Last edited:
If you just want to get 16/44.1 Toslink into the computer, I know of a couple of USB based units that will do the job:
miniDSP USBstreamer/MCHstreamer
HiFimeDIY UX1
Cost is about $100 or under, so not dirt cheap but not too expensive.
The USBstreamer is the better choice, since it can RX up to 192k IIRC and the firmware can be reprogrammed to do other modes like 8ch 48kHz ADAT.
These are definitely more plug and play compared to the HiFiBerry stuff, but neither have adjustable clocks AFAIK.
miniDSP USBstreamer/MCHstreamer
HiFimeDIY UX1
Cost is about $100 or under, so not dirt cheap but not too expensive.
The USBstreamer is the better choice, since it can RX up to 192k IIRC and the firmware can be reprogrammed to do other modes like 8ch 48kHz ADAT.
These are definitely more plug and play compared to the HiFiBerry stuff, but neither have adjustable clocks AFAIK.
He doesn't need a DAC. He is looking for INPUT of a Toslink signal into the computer.
Getting back to talking about synchronized streaming...
I've made some changes that have improved the performance all around:
The audio stream and NTP traffic are routed via their IP addresses, and this restricts them to one router or the other. I assign/reserve the IPs using my router software so that they will not change after a reboot or extended downtime. Because I am using Qos to prioritize audio stream packets on my network, this sometimes seemed to cause long intervals in which no NTP packet would make it to the machine, or they would take so long that they were marked as invalid by chrony.
Chrony has some nice features for keeping the local clocks well synchronized, but without jumps. This includes the "smoothtime" directive (for the server side on my local NTP server) and the "filter" directive for averaging the data in multiple NTP queries to reduce the amount of noise in the information. Also, chrony permits very short polling intervals, even sub-second intervals. This is OK if you are running your own NTP server and that is what you are polling (as opposed to a public NTP server on the web). So you can poll often and average the info, which helps to prevent over-correction. NTP was prone to this when short polling intervals (under 64 sec) were used.
The last change I made was to move from the 5.8GHz network to my 2.4GHz network since my router is on a different floor from the computers I am using to test this out, and the signal quality was not all that high. On the lower frequency band I am getting nearly 100% strength and quality levels. If everything was located on the same floor, or even in the same room, the 5.8GHz band would likely be fine.
I've made some changes that have improved the performance all around:
- I am now using chrony in place of ntp
- I installed a second wifi adapter on my computers
- I receive the audio stream on adapter #1
- I send/receive NTP requests/data on adapter #2
The audio stream and NTP traffic are routed via their IP addresses, and this restricts them to one router or the other. I assign/reserve the IPs using my router software so that they will not change after a reboot or extended downtime. Because I am using Qos to prioritize audio stream packets on my network, this sometimes seemed to cause long intervals in which no NTP packet would make it to the machine, or they would take so long that they were marked as invalid by chrony.
Chrony has some nice features for keeping the local clocks well synchronized, but without jumps. This includes the "smoothtime" directive (for the server side on my local NTP server) and the "filter" directive for averaging the data in multiple NTP queries to reduce the amount of noise in the information. Also, chrony permits very short polling intervals, even sub-second intervals. This is OK if you are running your own NTP server and that is what you are polling (as opposed to a public NTP server on the web). So you can poll often and average the info, which helps to prevent over-correction. NTP was prone to this when short polling intervals (under 64 sec) were used.
The last change I made was to move from the 5.8GHz network to my 2.4GHz network since my router is on a different floor from the computers I am using to test this out, and the signal quality was not all that high. On the lower frequency band I am getting nearly 100% strength and quality levels. If everything was located on the same floor, or even in the same room, the 5.8GHz band would likely be fine.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.