WaveIO with mpdPup Player
I am using my WaveIO with mpdPup as the transport front end. The combo is fantastic and highly recommended.
The mpdPup Administrator though is having a couple of issues that appear to be unique to WaveIO users:
1. SOX Upsampling to 176,400 or 192,000 does not work and causes crashes of MPD
2. When installing the WaveIO to mpdPup it is 'Muted' and therefore does not play any sound. Slightly complex Linux commands are required to unmute it.
Wondered if others have similar experiences?
Lorien - would you have any ideas why WaveIO causes these issues and any fixes that can be made?
Many thanks
Jonathan
I am using my WaveIO with mpdPup as the transport front end. The combo is fantastic and highly recommended.
The mpdPup Administrator though is having a couple of issues that appear to be unique to WaveIO users:
1. SOX Upsampling to 176,400 or 192,000 does not work and causes crashes of MPD
2. When installing the WaveIO to mpdPup it is 'Muted' and therefore does not play any sound. Slightly complex Linux commands are required to unmute it.
Wondered if others have similar experiences?
Lorien - would you have any ideas why WaveIO causes these issues and any fixes that can be made?
Many thanks
Jonathan
Maybe... What I can know for sure is that hirez69 does not want to be left out from it, that's why I keep a copy of this list somewhere safeMaybe some people delete his name by error, because when they arrive on the spreadsheet they first add themselves on the first position. After that they see that they must go to the end of the list, but they forget to rewrite hirez69 again.........
I don't know, just an assumption.......
Cheers, staki
Well, I didnt thought at this when WaveIO was designed but we can find some alternatives for it:
1. You can try to connect all the I2S buses together (WaveIO I2S > DAC1 + DAC2). I'm not a big fan of this option but seems to be the faster I can think of right now.
2. For a "decent" approach, you can use fanout buffers, as you stated above but you have to implement it carefully (PSU, traces, connectors, etc.).
3. Use isolated I2S for one DAC while the nonisolated for the remaining one. Anyway please note that NVE isolator will add delays to all the signals of the isolated I2S port, delays that are NOT synchronized later on with Flip-Flops or other logic with the other I2S port thus this alternative is not the best approach still can be used for testing purposes!
Thank you Jonathan for reporting this! Even if XMOS does not say anything about Linux distro's there are a lot of users that use WaveIO with this Linux variants.
Please follow the link below hoping it will help you:
Computer Audio Asylum
and search for WaveIO. Wlowes could give you some infos in his posts.
Another link:
Puppy Linux Discussion Forum :: View topic - OLD: mpdPup - Simplified MPD Music Server/Jukebox - v0.9.2
I hope it helps,
L
Hello Brian,
if the I2S targets are two CODs boards will the impedance go ok ?
Hope for it because i have ordered two CODs and want it to use(in dual-mono mode) with the Xmos Board.
Cheers frog...
Hi Lorien
The issues appear to lie with WaveIO (XMOS) and not the Linux software.
SOX at 176 and 192 work well with other sound cards attached to mpdPup.
Thanks
Jonathan
Hmmm...
maybe it is Lorien's code? Or the Linux USB is not set up right? I am using an XMOS based USB receiver (SOtM) board with Voyage/mpd and its works perfectly, actually teated all the way out to 24/352.8 KHz with special code in the XMOS. I know that Vortexbox also works perfectly with this XMOS based USB interface. I have heard of plenty of others using Linux with XMOS based interfaces...
maybe it is Lorien's code? Or the Linux USB is not set up right? I am using an XMOS based USB receiver (SOtM) board with Voyage/mpd and its works perfectly, actually teated all the way out to 24/352.8 KHz with special code in the XMOS. I know that Vortexbox also works perfectly with this XMOS based USB interface. I have heard of plenty of others using Linux with XMOS based interfaces...
Hello Lorien.
It seems that I'm slowly coming close to the point where I actually will start using the "Wave IO".
I'm hoping that you are up for a psu question.
I just bougth a few of these The TPS7A47 Eval Board H i F i D U I N O
TPS7A4700 Evaluation Module - TPS7A4700EVM-094 - TI Tool Folder
The other option is the "Placid" shuntregulator.
Question would be, wish one would you prefer and why ?
One is shunt, the other a seriesregulator, that might be of some importance or
is that unrelevant in this case ?
The TI looks promising to me, or am I missing something ?
Either way I'm aiming to feed one or the other from a fairly ambitious regulated "LT-1083" board.
Bye the way, stunningly beautiful product of yours
It seems that I'm slowly coming close to the point where I actually will start using the "Wave IO".
I'm hoping that you are up for a psu question.
I just bougth a few of these The TPS7A47 Eval Board H i F i D U I N O
TPS7A4700 Evaluation Module - TPS7A4700EVM-094 - TI Tool Folder
The other option is the "Placid" shuntregulator.
Question would be, wish one would you prefer and why ?
One is shunt, the other a seriesregulator, that might be of some importance or
is that unrelevant in this case ?
The TI looks promising to me, or am I missing something ?
Either way I'm aiming to feed one or the other from a fairly ambitious regulated "LT-1083" board.
Bye the way, stunningly beautiful product of yours
I'll get one WaveIO card and go to a friend of mine to kill his free time with few experiments on mpdPup as I'm a Windows victim and it's enough for me
Well barrows it could be, don't say no but my only concern was/is to keep the firmware close to original as much as possible just to avoid all kind of unpleasant results like Jonathan has posted above (supposing the issue lies in firmware). Moreover, changing few constants (like USB VID/PIDs, enabling DFU feature), remapping the pins and add a small routine for LEDs (when sample rate is changed!) could not be considered in my opinion as a "heavy" mods in the XMOS code.
It would be interesting to see how XMOS reference card is doing in Jonathan's system.Hello Lorien.
It seems that I'm slowly coming close to the point where I actually will start using the "Wave IO".
I'm hoping that you are up for a psu question.
I just bougth a few of these The TPS7A47 Eval Board H i F i D U I N O
TPS7A4700 Evaluation Module - TPS7A4700EVM-094 - TI Tool Folder
The other option is the "Placid" shuntregulator.
Question would be, wish one would you prefer and why ?
One is shunt, the other a series regulator, that might be of some importance or
is that unrelevant in this case ?
The TI looks promising to me, or am I missing something ?
Either way I'm aiming to feed one or the other from a fairly ambitious regulated "LT-1083" board.
Bye the way, stunningly beautiful product of yours
Thank you for your kind words! Hard to choose because both are good! Unfortunately I do not own any of them so I just speak from "theory": I guess Placid (Shunts in general) are preferred against series regs. but my first thought would be to use both: TI for series regulation and after that Placid for "fine tuning". Anyway, this seems to be quite overkill for many of us so, the best judge will be your ears. Test your audio setup with both of them and choose the one you like it most.
Warm wishes,
L
Edit: now I see that you already have a LT-based pre-regulator so I would suggest to choose Placid as a starting point in your experiments.
I just tested XMOS with Salas shunt and simple regulator based on LT1086, SBYV diodes and 2 caps - very little thing. Im not going to make any final statement but IMO theres not much difference in SQ. Another thing is I change these PSU between WaveIO and DAC as both need only 5V (CS4397 DAC with caps output). My system is based on planar headphones and I think I could hear much more nuances here. I would rather say that bigger improvement is connecting DAC to Salas and WaveIO to LT1086 based reg.
For the "decent" approach, won't the fanout buffers increase jitter?
I think that I will use the first solution, provided that the target impedance is sufficiently high, like BrianDonegan says (I probably will use two PCM1794A dacs, eventually two AD1955). And of course make use of cables of the same length for both dac chips.
That means that I will be forced to use the isolated output, because I can't imagine a way to put two coax cables on a single U.FL connector.......
You might...
Consider that Jeff Roland Designs decided against using multiple DAC chips in their Aeris DAC because they considered it basically impossible to insure that the two chips would be perfectly in sync. One might consider this marketing BS, but he price of the DAC, and the fact that they do use other expensive parts, seems to me to be an indication that they did not base this decision on the additional expense of adding another DAC chip.
Dual Mono DAC chips may create more problems than it solves...
Consider that Jeff Roland Designs decided against using multiple DAC chips in their Aeris DAC because they considered it basically impossible to insure that the two chips would be perfectly in sync. One might consider this marketing BS, but he price of the DAC, and the fact that they do use other expensive parts, seems to me to be an indication that they did not base this decision on the additional expense of adding another DAC chip.
Dual Mono DAC chips may create more problems than it solves...
The point behind summing multiple DAC's is to get closer to the ideal output. Sync should not be an issue since the output (unless an NOS dac with no reconstruction filter) is low pass filtered octaves below any clock. The multiple DAC trick is nearly 20 years old and works. You should get about a 3 dB noise floor reduction for every doubling of DAC's.
I think Accuphase has a DAC with something like 16 dac chips summed. With more chips the individual errors drop as a proportion of the whole. I could argue that running one DAC on the back side of the master clock from another may be a good thing. With 16 you could make a sort of "ring DAC" with some intrinsic low pass functionality. Not too different from how a SAW filter is made.
Any fast CMOS buffer will have phase noise (jitter) way below any clock you can buy. At 1 KHz any 74AC family chip can easily be -170 dBC phase noise, if you have a reasonably quiet power supply and did not screw up the grounding etc.
I think Accuphase has a DAC with something like 16 dac chips summed. With more chips the individual errors drop as a proportion of the whole. I could argue that running one DAC on the back side of the master clock from another may be a good thing. With 16 you could make a sort of "ring DAC" with some intrinsic low pass functionality. Not too different from how a SAW filter is made.
Any fast CMOS buffer will have phase noise (jitter) way below any clock you can buy. At 1 KHz any 74AC family chip can easily be -170 dBC phase noise, if you have a reasonably quiet power supply and did not screw up the grounding etc.
Last I looked 1 uS in air was about 1/1000 of a foot or .02 inch or so. ( maybe 1 mm?). Perhaps gravity is less where you are and things go faster (relativity. . .)
I didnt do any crunching of numbers at all, and should have oviously read mS. I had a feeling the word similar would bite me
. what I mean is there are bigger things to worry about.
Yet there are quiet a few examples of commercial or diy dacs that work with a dual mono implementation of two dac chips which share the same i2s signals without any buffers. And they seem to operate properly.......
Then where is the truth?
it would be interesting to know what delay a difference of 1 or 2 mm in cable length causes, depending on the speed of signal propagation in copper......
