What would your source be? Can't the source send the audio over ethernet directly?
Okay, show me a couple of audio sources that I can buy, easy to build, easy use (playlists) and delivering high quality audio over Ethernet. I have several terabytes of audio in various formats including 2496 vinyle rips on my Synology 213j NAS. In order to keep the Ethernet speakers as simple as possible, I expect the Ethernet audio source to reformat everything into 24-bit stereo audio @ 44.1 kHz in order to ensure a "bit perfect" transfer what's regarding legacy audio CD.
I suggest running LMS (the logitech squeezebox server) on the NAS, and using a raspberry pi or something similar running squeezelite at the receiving end. Why reformat? Just play everything in native format...
That's not enough, you must sync all channels (L/R and possible MID, SUB and surround channels). Also the I2C communication to two MikroE CODEC boards is a problem as they don't have configurable I2C addresses (might just work sharing the same address though). IP based systems need a proper protocol anyway, p2p might be easy using raw ethernet though. Analog (balanced or unbalanced depending on cable length) interconnections would be most convenient and not much worse than S/PDIF or like if you consider the jitter.
Atmel's new Cortex-M7 SAM V71 supports Ethernet-AVB protocol in hardware and comes with I2S/TDM audio port in SSC :
SAM V MCUs
Open AVB:
https://github.com/audioscience/Open-AVB
SAM V MCUs
Open AVB:
https://github.com/audioscience/Open-AVB
Last edited:
I guess this may be okay for transporting audio from a source to a player. I'm not sure this is okay for speakers. Please consider the following setup :
RAVENNA stereo audio source
4-port Ethernet Switch
port 1 connected to RAVENNA source
port 2 connected to RAVENNA Left Speaker embedding a 4-way digital xo
port 3 connected to RAVENNA Right Speaker embedding a 4-way digital xo
port 4 - free -
Both speakers need to request audio packets for obeying the asynchronous audio paradigm.
In such context, can the two speakers remain synced?
I would say no.
The Left Speaker is supposed to request packets basing on his local quartz.
The Right Speaker is supposed to request packets basing on his local quartz.
The two quartz will exhibit a slight frequency difference.
Thus, the two speakers will drift away.
What sync method would you deploy?
Can PTPv2 (IEEE 1588-2008) help maintaining a proper Left/Right synchronization without having to discard audio samples or without having to duplicate audio samples?
What time precision can be achieved?
Last edited:
Very nice chip indeed, albeit only one I2S. Need to rely on TDM. Can somebody advise a 4-channel DAC operating on TDM, preferably equipped with a high quality volume control?
AVB stereo audio source
4-port Ethernet Switch
port 1 connected to AVB source
port 2 connected to AVB Left Speaker embedding a SAM V71 as 4-way digital xo
port 3 connected to AVB Right Speaker embedding a SAM V71 as 4-way digital xo
port 4 - free -
What sync method is deployed within AVB?
Is the AVB sync method suited to the above layout?
Can the AVB sync method maintain a proper Left/Right synchronization without having to discard audio samples or without having to duplicate audio samples?
What time precision can be achieved?
I think AVB uses time stamps on audio packets, and either relies on NTP or sends wall clock inside control packages so that consumers can sync to producer.
E: AVB uses PTP (precision time protocol) not NTP.
Found this PDF after googling (Ethernet Speakers), interesting reading (though not related to AVB):
http://www.prevelakis.net/Papers/EthernetSpeaker.pdf
E: AVB uses PTP (precision time protocol) not NTP.
Found this PDF after googling (Ethernet Speakers), interesting reading (though not related to AVB):
http://www.prevelakis.net/Papers/EthernetSpeaker.pdf
Last edited:
"Audinate's Dante has won the race, while AVB is still being tweaked by the mechanics over in the pit lane."
AVB and Audinate's Dante: An Update After Infocomm 2014 ? Control Geek
Nevermind, XMOS is still supporting AVB, like MiniDSP (DSP4YOU).
http://www.dsp4you.com/products/avb-oem-series/avb-dg
E: Might be this is the master github for Open AVB, the above linked one is a forked one:
https://github.com/AVnu/Open-AVB
AVB and Audinate's Dante: An Update After Infocomm 2014 ? Control Geek
Nevermind, XMOS is still supporting AVB, like MiniDSP (DSP4YOU).
http://www.dsp4you.com/products/avb-oem-series/avb-dg
E: Might be this is the master github for Open AVB, the above linked one is a forked one:
https://github.com/AVnu/Open-AVB
Last edited:
Apparently, AVB requires AVB-compatible Ethernet switches. yes/no?
If yes, I fear this is a NOGO for the do-it-yourself context.
Same for Audinate's Dante?
If yes, I fear this is a NOGO for the do-it-yourself context.
Same for Audinate's Dante?
Let's consider this :
The 50ps RMS residual jitter that's entering modern jitter-insenstive DAC's is the approach I prefer.
Please tell me the DACs I shall use.
Please tell me the volume control IC I possibly shall use.
More is feasible, hooking a Wireless module on all ST Nucleo F411RE boards, using SPI. This way they can exchange general control and status data, beyond the volume control, at something like 100 kbit/s.
All this can be open-source, and free.
STM32 CubeMX (configuration utility) is free, and supporting the STM32 F411RE chip.
STM32 CubeF4 (code generator) is free, and supporting the STM32 F411RE chip.
KEIL MDK ARM 5.14 (C compiler) is free (albeit 32k limit, no code disassembly, no position-independent code or data), and supporting the ST Nucleo F411RE board.
- any digital audio source (PC, DVD, Blu-ray, TV, NetPlayer) outputting a stinking orange SPDIF cinch delivering 16-bit 48 kHz or 44.1 kHz stereo audio, and plenty of jitter
- a "SPDIF pre" embedding a WM8804 as SPDIF receiver and jitter buster (50ps RMS residual jitter), a ST Nucleo F411RE and two WM8804 as volume data injectors and jitter busters (50ps RMS residual jitter), outputting two SPDIF cinches (the white cinch is Left audio + Volume, the red cinch is Right audio + Volume)
- two "SPDIF speakers" featuring the white and red cinches as inputs, a hardware left/right selector, a WM8804 as SPFIF receiver and jitter buster (50ps RMS residual jitter), a ST Nucleo F411RE acting as 4-way digital xo, followed by two I2S stereo DACs clocked by the recovered SPDIF clock, those modern DACs to be known to be insensitive to jitter, and followed by a high quality volume control
The 50ps RMS residual jitter that's entering modern jitter-insenstive DAC's is the approach I prefer.
Please tell me the DACs I shall use.
WM8580 (6-channel delta/sigma DAC, with volume control)
TDA1387T (stereo NOS DAC, without volume control)
ES9023 (stereo delta/sigma DAC, without volume control)
CS4334 (stereo delta/sigma DAC, without volume control)
PCM5102 (stereo delta/sigma DAC, without volume control)
PCM5122 (stereo delta/sigma DAC, without volume control)
TDA1387T (stereo NOS DAC, without volume control)
ES9023 (stereo delta/sigma DAC, without volume control)
CS4334 (stereo delta/sigma DAC, without volume control)
PCM5102 (stereo delta/sigma DAC, without volume control)
PCM5122 (stereo delta/sigma DAC, without volume control)
Please tell me the volume control IC I possibly shall use.
PGA2311 (2-channel)
PGA4311 (4-channel)
I don't need more. I guess there could be many people like me, wanting decent (and affordable) SPDIF speakers embedding a 4-way digital xo.PGA4311 (4-channel)
More is feasible, hooking a Wireless module on all ST Nucleo F411RE boards, using SPI. This way they can exchange general control and status data, beyond the volume control, at something like 100 kbit/s.
All this can be open-source, and free.
STM32 CubeMX (configuration utility) is free, and supporting the STM32 F411RE chip.
STM32 CubeF4 (code generator) is free, and supporting the STM32 F411RE chip.
KEIL MDK ARM 5.14 (C compiler) is free (albeit 32k limit, no code disassembly, no position-independent code or data), and supporting the ST Nucleo F411RE board.
Last edited:
Synchronising speakers:
If the crystals in 2 speakers are left free running, how far do they actually drift in (say) 1 hour?
DACs & volume control:
Use the volume control within the sabre DAC (or other high resolution DAC of your choice)
If the crystals in 2 speakers are left free running, how far do they actually drift in (say) 1 hour?
DACs & volume control:
Use the volume control within the sabre DAC (or other high resolution DAC of your choice)
I'd also dearly love to know how multiple speakers' XTALs can remain sync'd in practice. Anyone studied this in depth to be able to give a concise answer?
@ChrisPa - a typical XO might have 30ppm accuracy. So that's a drift of roughly 100mS in 1hour.
Last edited:
Bolded is my choice when listening satisfaction (rather than measurements) is uppermost. Also far and away the cheapest ($0.10). Having a DAC without broadband HF noise output means its sensitivity to jitter (subjectively) is lower.
I'd choose neither of those - currently I go for AD603 but AD605 can work fine too. The former is only a single channel but purchased from Taobao ($0.60) even four of them are cheaper than the PGA2311 (list price $4). The attenuation range is lower though (only 42dB). However since the volume is DC controlled, the software to drive them is much simpler (a DAC or PWM output suitably LP filtered).
Last edited:
I suspect we may well be reinventing the wheel here - we're not the first to have considered this problem. On the other hand, that doesn't mean it's not possible to make a better wheel.
You have the options of existing/conventional techniques to synchronise clocks eg
- word/multi-word (eg every 100th word) clock
- other variations on occasional resynchronisation - every minute, every hour, during quiet passages
- pll derived from time synchronisation packets
- ptp looks interesting Precision Time Protocol - Wikipedia, the free encyclopedia
I'm not interested in new ways to sync clocks, just curious how good existing ways are and whether they're audibly acceptable to apply to digital speakers.
No, two AVB-compatible endpoints can work over a non-AVB-aware switch as long as it is fast (predictable) enough. Synchronization is part of the protocol.
Actually this is 108 ms.
Another perspective is to determine the playing time causing the crystal drift to become equal to a sample period. For Fs = 48 kHz, this is 694 ms. I guess no audiophile would tolerate a system possibly duplicating or skipping one audio sample every 500 ms for maintaining the left channel in sync with the right channel.
I feel much more reassured with SPDIF, whose PLL-recovered 256 x Fs clock acts as master clock, provided :
- there are WM8805 chips on the path acting as jitter busters,
- the DACs that are used are known for being quite jitter-insensitive
Is it okay to have the following clocking scheme :
- WM8805 generating the WM256FS clock signal (PLL-recovered master clock)
- configuring the F411RE I2S4 interface as Half-Duplex Slave (audio Rx from WM8805)
- configuring the F411RE I2S3 interface as Half-Duplex Slave (audio Tx to ES9023 #1)
- configuring the F411RE I2S2 interface as Half-Duplex Slave (audio Tx to ES9023 #2)
- routing the WM256FS clock to both ES9023
In such context, do we need to add D-type flip-flops on all I2S lines between the F411RE and both ES9023 for guaranteeing the synchronization of all ES9023 I2S input pins ?
I remain skeptic about relying on the supposedly 112 dB dynamic range (DNR) of the ES9023 DAC for implementing the volume control. Does it mean that the signal / noise ratio in the audio band would remain a healthy and quite tolerable 82 dB, when listening at a -30 dB volume ?
Even if that's the case, I remain skeptic.
IMO, many power amplifiers are susceptible to ultrasonic content, what's regarding the subjective listening results. As soon as you start sending ultrasonic garbage to them, you'll get deceptive subjective listening results.
IMO, some analog volume control is mandatory, just after the ED9023 DACs.
ES9023 can only be used as slave, so there must be a separate clock generator if F411RE is also used as slave. For a clock generation an ADC like WM8786 working in master mode would be fine.
- Status
- Not open for further replies.