peufeu said:
What do you mean by weak ?
FPGA should never be used to process an audio clock, for instance, you have to reclock at the DAC. Otherwise, it rocks
My point is:
* Reclocking the stream at the DAC won't recover the "jitterless" source data if these are messed up earlier upstream.
* The latency you get into the stream due to the FGPA we discussed
some time ago. This will need some extra buffering.
* RAM is pretty limited on your FGPA but might be sufficiant for
streaming purposes
* I wonder if DSP (brutefir) would be done by the FGPA or on your
server. I doubt that your FGPA does the DSP work - right?
* Below GBit-ethernet, I wouldn't touch ethernet in context of
uncompressed audio transfer for storage and full-file buffering purposes.
* BTW. the ethernet interface is eating up quite some resources on the server. That might have an impact on the other IRQ managed processes and devices. You would have to increase buffers again.
You know -- I don't like buffers!
However. If everything in the chain is in sync, your approach could work.
I'll follow your progress.
Cheers
soundcheck said:
I really have to say that I completely fail to understand your perspective and approach. You seem to be missing the point that if you solve the clocking issue, then nothing else matters AT ALL. Assuming fixed DAC/analog components, the ONLY ways that a digital playback system can influence the sound are
a) data corruption
b) clock corruption
We know that a) isn't happening in any sanely constructed system. Therefore if your system sounds different every time you touch something, then you're clearly dealing with b. Why would you continue with an approach that has proven itself so sensitive to clock corruption that you can't sneeze without it sounding different? Peufeu's approach eliminates b about as well as any approach can; I may be going out on a limb, but I'd suggest that any system containing a PLL will be inferior.
The only comparable diy-ish system I've run across is Empiricals Pace Car, where Steve is 'exporting' the master clock back to the source. Being a boutique supplier though, this is very expensive and also requires modifying the souce.
SPDIF loopback used to slave the PC to a clock in a combined AD/DA unit can accomplish much the same thing, but there currently seems to be a dearth of units that support this. The Art DI/O does/did, but was compromised by marginal parts quality.
If there are other 'easier' ways to solve the clock problem, I'd ask
a) what are they?
b) why aren't you using them?
(hint: if your answer to a uses a pll, then try again)
Sure you do. What do you think you're doing when you read the entire file into RAM for playback? You're buffering the data. By removing the buffers from the output end and placing them at the source end you're compromising the isolation of the device from system activity, and then trying to compensate by reducing system activity in the first place. The fact that you end up with a multi-GHz cpu with GB+ levels of ram to basically do nothing but move data from a set of I/O buffers to a set of output DMA buffers and yet *still* have a system that is sensitive to activity suggests that there is something rather inefficient in the basic approach.
Perhaps this is the fundamental problem. The is no *RE*clocking. There is only *clocking*. Jitter can not be introduced 'upstream', because for the clock there is no 'upstream'.
dwk123 said:
1. Steve reported that even his pacecar does show differences if you improve
the situation further upstream. Your reasoning is not at all plausible to me.
Perhaps you have better benchmarks then Steves pacecar.
2. Why don't you just take a PCI soundard, slave it to your external masterclock
and tap off the I2S for you own DAC. That's the easiest solution I see.
I doubt that it's gonna be worse than Peufeus approach.
3. I am not doing it - running for a more complicated approach - because the
sound I get from my tweaked USB setup is that good, that I actually don't have
the feeling that I'd need it any better. Nor I have the drive to spent thousends
of dollars for off-the-shelve HW. I burned enough money during my audio-life.
4. Sorry, but the RAM-buffer you're refering to, is not a buffer. It is a
filesystem. That I'd call somewhat a slight difference!
dwk123 - How about any constructive comments to improve the Linux setup?
(The DAC discussions are a bit off-topic!)
Cheers
I tried it, it works well, with a RME Digi96/8 on Linux. I put the clock in the DAC, used a SPDIF encoder to send it to the soundcard, and the soundcard sent SPDIF back to the DAC, in sync with the master clock.
It's the easy easy way to do it if you want a format that SPDIF can handle (stereo...) For multichannel, you'd have to use ADAT with several fiber optics, and bunching channels together for higher sample rates (since ADAT supports 48k), then it tends to get a bit complex.
peufeu said:
What I mean:
Just take the I2Sout from a VIA chip. The VIA chip has a master clock input - right, so it can easly be slaved. NO SPDIF or similar conversions in between. You just have to be very close to the VIA chip with the DAC, due to the known I2S limitations.
But that would be the same in your FPGA setup with an I2S out. What you'll lack with the PCI approach compared to ethernet is the galvanic isolation. (One question remains though: is the galvanic ethernet isolation really lossless in audio terms?)
If you run your AUDIO PCI interface at highest priority under Linux it'll most probably rock. I guess you won't find a shorter path in a PC environment ( HW- and SWwise).
If I had some more time I'd immediately start with above project, because it would also get me multiple synched channels for an active speaker setup.
Cheers
soundcheck said:
If I am not mistaken, what you discribe here is a PCI soundcard .
I2S from a chip to the Dac is exactly what happens in my Bluegears. After all the tweaks I did to it, the resulting sound is much better than my USB DDDac.
Now if I had a better clock and a dedicated PS for the card no telling......
Makes me wonder if the PC inviroment has as much bearing on the sound as some make us believe.
Klaus
PCI Extender
Klaus,
I can recommend this company for PI extenders both rigid and flexible.
http://www.adexelec.com/pci32.htm
Klaus,
I can recommend this company for PI extenders both rigid and flexible.
http://www.adexelec.com/pci32.htm
soundcheck said:
If the budget allows, such a product already exists - the M-Audio Delta 1010. It brings the I2S lines to a DB25 port for connection to the external dac box. Pull the existing crystals and replace them with a good clock, and then either mod the heck out of the dac box or just route the I2S signals to your own setup. [I own one, and such a project has been on my 'maybe' list for quite a while]
Well, there are other differences, although it's still a good approach. You have (probably) longer I2S lines, less EMI isolation, and less ability to remote the PC. Keeping the clock power supply clean might be the biggest challenge - both from a power/ground perspective and from an EMI perspective.
I don't understand this statement. Are you suggesting that a transformer coupled ethernet connection between devices might introduce some *audio* artifacts?
There are many off-the-shelf ways to get multiple sync'd channels already, so this type of project (or the FPGA for that matter) is hardly a necessary precursor. I was doing active xovers using BruteFIR and a Delta 66 soundcard 8+ years ago, and the quality of multi-channel cards has only gotten better. IMHO worrying about the quality of the soundcard "up front" is a mistake - get the system architecture right first, the speaker/xover right second, and only after that worry about the sound card output.
However, even my Emu 1820M (which I think is a VERY good source in it's own right) falls a step short of ultimate sound quality in stock form, so if you want truly state-of-the-art reproduction for multi-channel output, you probably wont' get it without some degree of DIY. This is exactly why I'm so interested in the FPGA approach - it's the first thing I've come across that appears to offer a true upgrade over what I have.
soundcheck said:
Well, I'd first ask 'which pacecar'? There is also a USB version which uses a form of PLL which could conceivably be sensitive to upstream factors, although I'm still skeptical. If Steve really is saying that his pacecar-modded Squeezebox is still sensitive to activity on the machine that Slimserver is running on, then to be honest I don't buy it.
Not much actually. The kernel will always buffer file I/O into internal buffers for transfer to user space, particularly when the I/O pattern is sequential. You're still looking at interrupt-driven memory-to-memory transfers. If you want to split hairs it's probably actually worse to have it on a ram-based filesystem rather than read into I/O buffers, but since you probably don't have any control over buffering at that level it's a bit of a moot point.
4. Sorry, but the RAM-buffer you're refering to, is not a buffer. It is a
filesystem. That I'd call somewhat a slight difference!
dwk123 - How about any constructive comments to improve the Linux setup?
(The DAC discussions are a bit off-topic!)
Cheers
Well, I've been off Linux as my audio platform for a couple years, so my experience is stale. I am getting back into the game though, and will be setting up a spare machine as soon as I can. However, my approach to Linux audio starts with Jack, so I doubt there is much I've done that would influence what you're doing.
However, I think the coolest thing to surface recently (aside from peufeus project) is the Asus EEE notebook. (one report here http://www.hothardware.com/Articles/Hands_on_with_the_ASUS_Eee/). Completely flash based 2-pound notebook with a 900 MHz Pentium-M class cpu. It looks like the entry level versoin will be an 8Gb unit which will run ~$250 rather than the 4GB $200 version that has been reported on. Still, I can't imagine a better platform for a Linux audio computer if you can output over USB or ethernet (assuming the memory is upgradable - only 512M stock). 900MHz is enough for a pretty good BruteFIR setup, although it might get dicey at higher sampling rates. (I ran a 3-way setup with 128k tap filters @96kHz on a 1.2GHz athlon a couple years ago for reference). You'd obvoiusly have to store your media files on a network share, but it wouldn't preclude what you do with copying into a RAM disk if you upgrade . The big downside is that I suspect that these things might be very scarce for a while after their release.
brutus - The player that makes the dog barking
Hi folks.
I owe you a report of the event which took place yesterday in Holland at
Bert Doppenbergs place.
"brutus meeting XX" (xx @ www.phasure.com)
IMO - from my very personal perspective - the event of the year!
With below, I try to stay as objective as possible:
Both players are made to squeeze the best out of the Linux resp. Vista.
No other sw-player we ( the active team around this little project) came across,
seems to be better then these.
The system we took for the benchmarking exercise were BD Oris Swing Horns, BD CracyA Amps and a Django - passive S&B 102 based preamp. This I'd call a top-end audio chain.
The DAC has been a USB-TwinDAC and a RME Fireface400-TwinDac combo.
(you can find all above equip. at Bert's homepage)
I brought my all-time reference CD - Manger - Musik wie von einem anderen Stern ( Music - like from a different planet).
The key issue for testing is that you really got the same material for testing.
During the tests we figured that the same CDs can sound much different if badly ripped. Perhaps even the CDs itself do have a different quality!
We all had the feeling that the Manger CD was ripped OK for testing purposes.
We selected track 15-Jazz Variants a percussion piece, which pretty much allows
to test all frequencies, timbres, transients, complexity, soundstage.
A further advantage of this CD is that there has not been any gain added during the re-mastering.
Side-Note: We all did agree during the audition that all XRCDs and
the very popular "6db-gain-lift" done on many of the new recordings are just unacceptable and more than destructing to sound quality.
Back to the test:
Test Part I:
With DJANGO (S&B TX102 passive Transformer Pot):
We did quite some back and forth testing. I think the conclusion was that
the lower end and the highs were more clear with brutus. To quote
PeterST ( the XX responsible) more fresh. I felt also better transients with brutus.
brutus also genetrated a much wider stage. Sometimes I had the feeling that
XX had a bit more of details. It was hard to tell though.
Peter mentioned that he thinks brutus is lacking the mids. I was wondering if this is because the more present highs and lows. I didn't realize it anyhow.
One finding: Next time the test environment would have to be prepared much better, that's for sure, to really have the same conditions for both players.
I didn't mention yet that we run the show on two different PCs!
In the end this test was not really ending up in a day and night difference.
There were still a huge bunch of parameters which could have been changed,
but due to time constraints, we left it as it was at this stage.
In the end I was more than happy with the result of test part I. not knowing what would happen in part II.
Test Part II:
Without Django (S&B TX102 passive Transformer Pot) -- Direct DAC-AMP coupling:
One of the main intentions developing brutus was to get rid of a preamp by doing
sw-based volume control.
This feature is not embedded into XX. I am running brutus at 64bit
to do the volume control.
We were a bit sceptical about the gain in Berts chain. His speakers are running
at 114db - SPL and his amps are adding 27db. Compared to 98db and 21db in
my chain this was a major risk that the volume would have to be digitally-attenuated too much on Berts setup.
However, all of us were quite surprised when we realised that at -12db the whole
thing was in the right range. His Twin-DAC output stage is most probably delivering a much lover output level than my 24DDDAC.
The test - To make a short story even shorter.
It took not even 10 seconds to hear what's going on there!
The transients were shockingly steep. The dynamics are increasing so much you wouldn't believe it. You'll experience the well known "Towel-Take-Away"-effect"
to me this was now definetly a day and night difference.
Peters short comment: Yeah - it seems that we're listening to the Django sound all the time. I'd call it soft-washed sound.
Bert still felt, that Django delivers a more musical and integrated sound. IMO
Django filters quite some stuff out. That can't be it!
Unfortunately with the applied cabling ( 2*1m RCA bridged on the Django outputs) Bert caught some hum on his chain, which we couldn't resolve in the short time. His whole chain is optimised with Django playing a major role in there. IMO it would need a bit of adjustment to get an more integrated sound as he called it.
From my perspective the seperation was now outstanding, I liked it very much.
Perhaps because I am used to it since a while by now.
Conclusion:
With brutus I am on the right track. Soundwise brutus is able to challenge everything what's out there. With the internal volume control nothing comes
close to it.
XX is definately the first choice for a player application under MicroSoft.
Nothing under MS comes close to XX that's for sure
(I doubt that you'll find anything like that under OS-X either).
It also delivers nice features. Peter is also not tweaking around with the environment as I am doing it - XX is still a Windows based application.
From that perspective it is amazing what his application delivers in sound quality.
Another point to mention - God knows if it was by accident - It seemed that
even Berts big,big dog was kind of disturbed by brutus. It seemed that when
brutus playback was started - the dog began to bark. I experienced the same effect with a different dog once at a friends place, when a real piano started to play.
Finally thanx to Peter and Bert, as two commercial audio freaks, to have the guts to join such a benchmarking, with a hifi hobbyist.
Cheers
\Klaus
Hi folks.
I owe you a report of the event which took place yesterday in Holland at
Bert Doppenbergs place.
"brutus meeting XX" (xx @ www.phasure.com)
IMO - from my very personal perspective - the event of the year!
With below, I try to stay as objective as possible:
Both players are made to squeeze the best out of the Linux resp. Vista.
No other sw-player we ( the active team around this little project) came across,
seems to be better then these.
The system we took for the benchmarking exercise were BD Oris Swing Horns, BD CracyA Amps and a Django - passive S&B 102 based preamp. This I'd call a top-end audio chain.
The DAC has been a USB-TwinDAC and a RME Fireface400-TwinDac combo.
(you can find all above equip. at Bert's homepage)
I brought my all-time reference CD - Manger - Musik wie von einem anderen Stern ( Music - like from a different planet).
The key issue for testing is that you really got the same material for testing.
During the tests we figured that the same CDs can sound much different if badly ripped. Perhaps even the CDs itself do have a different quality!
We all had the feeling that the Manger CD was ripped OK for testing purposes.
We selected track 15-Jazz Variants a percussion piece, which pretty much allows
to test all frequencies, timbres, transients, complexity, soundstage.
A further advantage of this CD is that there has not been any gain added during the re-mastering.
Side-Note: We all did agree during the audition that all XRCDs and
the very popular "6db-gain-lift" done on many of the new recordings are just unacceptable and more than destructing to sound quality.
Back to the test:
Test Part I:
With DJANGO (S&B TX102 passive Transformer Pot):
We did quite some back and forth testing. I think the conclusion was that
the lower end and the highs were more clear with brutus. To quote
PeterST ( the XX responsible) more fresh. I felt also better transients with brutus.
brutus also genetrated a much wider stage. Sometimes I had the feeling that
XX had a bit more of details. It was hard to tell though.
Peter mentioned that he thinks brutus is lacking the mids. I was wondering if this is because the more present highs and lows. I didn't realize it anyhow.
One finding: Next time the test environment would have to be prepared much better, that's for sure, to really have the same conditions for both players.
I didn't mention yet that we run the show on two different PCs!
In the end this test was not really ending up in a day and night difference.
There were still a huge bunch of parameters which could have been changed,
but due to time constraints, we left it as it was at this stage.
In the end I was more than happy with the result of test part I.
not knowing what would happen in part II. Test Part II:
Without Django (S&B TX102 passive Transformer Pot) -- Direct DAC-AMP coupling:
One of the main intentions developing brutus was to get rid of a preamp by doing
sw-based volume control.
This feature is not embedded into XX. I am running brutus at 64bit
to do the volume control.
We were a bit sceptical about the gain in Berts chain. His speakers are running
at 114db - SPL and his amps are adding 27db. Compared to 98db and 21db in
my chain this was a major risk that the volume would have to be digitally-attenuated too much on Berts setup.
However, all of us were quite surprised when we realised that at -12db the whole
thing was in the right range. His Twin-DAC output stage is most probably delivering a much lover output level than my 24DDDAC.
The test - To make a short story even shorter.
It took not even 10 seconds to hear what's going on there!
The transients were shockingly steep. The dynamics are increasing so much you wouldn't believe it. You'll experience the well known "Towel-Take-Away"-effect"
to me this was now definetly a day and night difference.
Peters short comment: Yeah - it seems that we're listening to the Django sound all the time. I'd call it soft-washed sound.
Bert still felt, that Django delivers a more musical and integrated sound. IMO
Django filters quite some stuff out. That can't be it!
Unfortunately with the applied cabling ( 2*1m RCA bridged on the Django outputs) Bert caught some hum on his chain, which we couldn't resolve in the short time. His whole chain is optimised with Django playing a major role in there. IMO it would need a bit of adjustment to get an more integrated sound as he called it.
From my perspective the seperation was now outstanding, I liked it very much.
Perhaps because I am used to it since a while by now.
Conclusion:
With brutus I am on the right track. Soundwise brutus is able to challenge everything what's out there. With the internal volume control nothing comes
close to it.
XX is definately the first choice for a player application under MicroSoft.
Nothing under MS comes close to XX that's for sure
(I doubt that you'll find anything like that under OS-X either).
It also delivers nice features. Peter is also not tweaking around with the environment as I am doing it - XX is still a Windows based application.
From that perspective it is amazing what his application delivers in sound quality.
Another point to mention - God knows if it was by accident - It seemed that
even Berts big,big dog was kind of disturbed by brutus. It seemed that when
brutus playback was started - the dog began to bark. I experienced the same effect with a different dog once at a friends place, when a real piano started to play.
Finally thanx to Peter and Bert, as two commercial audio freaks, to have the guts to join such a benchmarking, with a hifi hobbyist.
Cheers
\Klaus
You might have some supersonic ringing or aliasing too. That would set the dog off. It would be good to confirm this is not the case.
I presume Brutus upsamples to 88.2k or higher. I doubt the upsampling can put back information that wasn't in the 44.1kHz sample. You need to use the same dog with the real piano and the recording.
I presume Brutus upsamples to 88.2k or higher. I doubt the upsampling can put back information that wasn't in the 44.1kHz sample. You need to use the same dog with the real piano and the recording.
Hi folks.
To get you the full picture on the XX vs. brutus benchmarking exercise:
By following below link you can read some comments from
the people which were present at the benchmarking exercise.
http://forum.bd-design.nl/forum_entry.php?id=14392
I can assure you the meeting was not meant to be a contest. It was meant to be a real life benchmarking exercise.
Berts comments in his post at BD-Design I support very much.
If you look at his entire chain, XX and his chain are a 100% match, delivering a very nice musical and very detailed sound.
However, I strongly believe with a chance to tweak brutus some hours at Berts system and on top preparing his system for direct DAC-AMP coupling the situation would have been somewhat different.
I think Peter realized the direct coupling potential.
Sooner or later he'll might think about a digital volume control for XX.
Within my chain everything sounds fine - at least to me!
Bert also mentioned he had a feeling that I was adding gain to the signal. I do not add gain - at least I am not aware of it.
I realised in the past the better brutus and the Linux setup got, the better the lower end and the transient response was.
I am sure Peter would confirm that behaviour in general.
He made a similar experience when developing XX.
Bert also made a valid point that, except the Manger reference CD we mainly used for the listening tests, which was ripped from the same source, all other CDs sounded quite different. (We actually tried 2 others Officium-Track 1 and Jazz in the Pawnshop - Track 3 - ripped from different source material)
Next time I'd propose to use the same PC with the same data material for both players anyhow.
One more comment related to Peters comment at BD-Design:
In my chain I managed recently to get the amp gain down by 6db, which leads now to approx. -6db digital volume attentuation for my prefered listening level on most of the CDs. I am not running in the range of -10-12db attenuation as I did earlier.
That'll be it for now - I'll keep you posted.
Cheers
\Klaus
To get you the full picture on the XX vs. brutus benchmarking exercise:
By following below link you can read some comments from
the people which were present at the benchmarking exercise.
http://forum.bd-design.nl/forum_entry.php?id=14392
I can assure you the meeting was not meant to be a contest. It was meant to be a real life benchmarking exercise.
Berts comments in his post at BD-Design I support very much.
If you look at his entire chain, XX and his chain are a 100% match, delivering a very nice musical and very detailed sound.
However, I strongly believe with a chance to tweak brutus some hours at Berts system and on top preparing his system for direct DAC-AMP coupling the situation would have been somewhat different.
I think Peter realized the direct coupling potential.
Sooner or later he'll might think about a digital volume control for XX.
Within my chain everything sounds fine - at least to me!
Bert also mentioned he had a feeling that I was adding gain to the signal. I do not add gain - at least I am not aware of it.
I realised in the past the better brutus and the Linux setup got, the better the lower end and the transient response was.
I am sure Peter would confirm that behaviour in general.
He made a similar experience when developing XX.
Bert also made a valid point that, except the Manger reference CD we mainly used for the listening tests, which was ripped from the same source, all other CDs sounded quite different. (We actually tried 2 others Officium-Track 1 and Jazz in the Pawnshop - Track 3 - ripped from different source material)
Next time I'd propose to use the same PC with the same data material for both players anyhow.
One more comment related to Peters comment at BD-Design:
In my chain I managed recently to get the amp gain down by 6db, which leads now to approx. -6db digital volume attentuation for my prefered listening level on most of the CDs. I am not running in the range of -10-12db attenuation as I did earlier.
That'll be it for now - I'll keep you posted.
Cheers
\Klaus
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.