One more comment to that nasty and boring earlier discussion.
edwildgoose ( and some others even seconding this) discredits himself to wipe out "any" points I'm making. I can't really get him away with that kind of responses. He is not even properly reading what I am writing.
Some examples:
He is trying to sell a HDSP9632 as a top audio multichannel interface by just talking about
very convincing argument - probably copied from the marketing leaflet - no, no, no way, that can't be the case, because RME would have serious difficulties to explain how they'd measure "performance".
And he even achieves amazing 3*2 channel =6 * 110db "performance".
Probaly that's possible with RME-HW related Alsa tools such as HDSP-Mixer which have been updated just recently in "2003". Pretty impressive.
For HW related DIY and modification discussions , in case you are interested to learn a bit more about it, I'd like to refer you to the digital section of DIY-Audio. There you'll quickly learn what's wrong with your RME ( start with the PS and power conditions inside a PC, followed by the opamps and output stage and don't to forget to read about the impact of extensive digital attenuation. .
or
On my comment:
He responds:
Anybody around who'd be able to figure out any logic on that response?
Very funny logic. This is getting ridiculous.
Instead of discussing the well known losses associated to FIR filters, he is coming up with nonsense he associates to me - things I never said.
This I consider a pretty poor attitude. His intentions behind this are obviously more then obvious.
In fact - these kind of discussions should be censored by the admins. I don't see any value-add having these kind of discussions.
I just wasted another 10 minutes reading that nonsense and writing this post.
Cheers
edwildgoose ( and some others even seconding this) discredits himself to wipe out "any" points I'm making. I can't really get him away with that kind of responses. He is not even properly reading what I am writing.
Some examples:
He is trying to sell a HDSP9632 as a top audio multichannel interface by just talking about
very convincing argument - probably copied from the marketing leaflet - no, no, no way, that can't be the case, because RME would have serious difficulties to explain how they'd measure "performance".
And he even achieves amazing 3*2 channel =6 * 110db "performance".
Probaly that's possible with RME-HW related Alsa tools such as HDSP-Mixer which have been updated just recently in "2003". Pretty impressive.
For HW related DIY and modification discussions , in case you are interested to learn a bit more about it, I'd like to refer you to the digital section of DIY-Audio. There you'll quickly learn what's wrong with your RME ( start with the PS and power conditions inside a PC, followed by the opamps and output stage and don't to forget to read about the impact of extensive digital attenuation. .
or
On my comment:
He responds:
Anybody around who'd be able to figure out any logic on that response?
Very funny logic. This is getting ridiculous.
Instead of discussing the well known losses associated to FIR filters, he is coming up with nonsense he associates to me - things I never said.
This I consider a pretty poor attitude. His intentions behind this are obviously more then obvious.
In fact - these kind of discussions should be censored by the admins. I don't see any value-add having these kind of discussions.
I just wasted another 10 minutes reading that nonsense and writing this post.
Cheers
Hi folks.
Some constructive information related to hdcd decoding:
Download the Windows binary here:
binary in zip-archive
Open a terminal
wine needs to be installed first (sudo apt-get install wine)
Download, unzip and extract the binary into your home dir.
Make it executable ( chmod 777 hdcd.exe).
Have a look at the options:
That's how the HDCD flag can be detected:
Now you just need to write a little script that scans the entire collection - one track per album.
One thing just hits my mind:
I guess flacs need to be decoded first. In this case you'll loose your tags. I need to look into that one too sooner or later.
Anyhow. You should give it a try. Enjoy.
Cheers
Some constructive information related to hdcd decoding:
Download the Windows binary here:
binary in zip-archive
Open a terminal
wine needs to be installed first (sudo apt-get install wine)
Download, unzip and extract the binary into your home dir.
Make it executable ( chmod 777 hdcd.exe).
Have a look at the options:
Code:
~ $ ./hdcd.exe -hThat's how the HDCD flag can be detected:
Code:
~ $ ./hdcd.exe -i ./01-Holly_Cole-Romantically_Helpless-One_Trick_Pony.wav
HDCD DetectedNow you just need to write a little script that scans the entire collection - one track per album.
One thing just hits my mind:
I guess flacs need to be decoded first. In this case you'll loose your tags. I need to look into that one too sooner or later.
Anyhow. You should give it a try. Enjoy.
Cheers
One more.
I am about to convert my entire collection to flac to get a consistant and extended tagging in place.
I've been looking for a reasonable tagging tool under Linux comparable to mp3tag. There was easytag and some other stuff not worth to mention. Hmmh.
By accident I stepped over a brand new tool called puddletag ( the look and feel it is pretty similar to mp3tag).
It is not 100% stable yet, though they are working on it.
For now it is the best tagging tool I could find under Linux.
You can download it here.
I use the svn version. ( you just install the basic package first and copy the svn downloads over the existing files)
Enjoy.
Cheers
I am about to convert my entire collection to flac to get a consistant and extended tagging in place.
I've been looking for a reasonable tagging tool under Linux comparable to mp3tag. There was easytag and some other stuff not worth to mention. Hmmh.
By accident I stepped over a brand new tool called puddletag ( the look and feel it is pretty similar to mp3tag).
It is not 100% stable yet, though they are working on it.
For now it is the best tagging tool I could find under Linux.
You can download it here.
I use the svn version. ( you just install the basic package first and copy the svn downloads over the existing files)
Enjoy.
Cheers
the cmd line "hdcd" decoder by Christoper Key can both detect and/or decode a wav file...
Code:
$ hdcd -h
hdcd 0.1
Usage: hdcd [-h] [-o output | -c | -a] [-x] [-i] [-r] [-s] [--] file
Upconvert a 16 bit wav file to 24 bit using HDCD encoding if present
Options:
-v display version number
-h display usage information
-o output output to the specified file
-c output to stdout (Default)
-a suppress output
-x return a non-zero exit code if HDCD
encoding wasn't detected.
-i identify HDCD. Only scans the first 750
frames or until HDCD encoding is
detected. Implies -a -x.
-r treat input as 2ch, 16 bit raw PCM and
and write output as 2ch, 24 bit raw PCM.
-s only write warnings and errors to stderr
-- allow file to start with '-'
file input file. Defaults to stdin.
Copyright (c) 2006-2007 Christoper Key.
Permission is hereby granted to use, copy, modify, merge, publish, distribute,
sublicense, and/or sell copies of this software (the "Software"), subject to
the following conditions:
This notice be included in all copies and substantial portions of the
Software.
The Software shall not be used in any manner that infriges the rights of any
third parties, including but not limited to those arising from US Patents
5,479,168 and 5,872,531.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
HDCD is a registered trademark of Microsoft Corporation.send an e-mail to the author to get the source code.
He distribute it freely to whoever asks for it, but does not want it to be redistributed by anyone else (in any form & by any means).
Last edited:
Paper
Hello,
a collegue of mine at CCRMA (Stanford Unversity) (co)wrote a nice paper on latency. I guess it is the first and only piece of academic literature on the subject:
http://www.cnmat.berkeley.edu/system/files/attachments/latencytest.pdf
All the Best Wishes
Pietro
Hello,
a collegue of mine at CCRMA (Stanford Unversity) (co)wrote a nice paper on latency. I guess it is the first and only piece of academic literature on the subject:
http://www.cnmat.berkeley.edu/system/files/attachments/latencytest.pdf
All the Best Wishes
Pietro
Last edited by a moderator:
I am afraid the tested kernel 2.4.25 is WAY too ancient to make any conclusions for current linux.
I read that paper and was seriously disturbed by how flawed their: methodology was, the gaps in the knowledge forming the basis of the experiment and as a result my opinion of Berkley has fallen through the floor.
Ignoring the age of the paper, and the operating systems tested here's a quick (but not complete) tour of why I made the comment above.
Test Methodology
1) To isolate an effect then other than the variables under test everything else must remain the same. Here you have three totally different computers, each with a totally different audio interface (each using a different bus to talk to the machine). The number of variables introduced as a result makes all their conclusions invalid before they generated the first impulse
2) Not only do they use dissimilar hardware for each platform they are using different software (and even when using the same software they use different versions of software). By not using consistent software testing methodologies accross the platforms all their conclusions are invalid.
Weak Knowledge
1) Assuming that there should be Zero samples of latency when audio is passing through a digital interface is plain wrong
2) "Proving" that there is no bandwidth limitation in the manner they did doesn't actually prove what they say it does. That they're using SP/DIF will have influence on their results due to bandwidth restrictions...
3) Not understanding how their test apparatus might introduce unexpected results and take steps to ensure that isn't the case.
There's a whole pile more wrong with this paper, but the testing methodology alone is enough to invalidate anything but 3 sets of distinct measurements of 3 uncorrellated systems.
What WOULD be in an interesting paper is take a Mac Pro (Reference Intel Architecture) and test it with a selection of interfaces under all three OSes (Using boot camp for native access to hardware).
Ignoring the age of the paper, and the operating systems tested here's a quick (but not complete) tour of why I made the comment above.
Test Methodology
1) To isolate an effect then other than the variables under test everything else must remain the same. Here you have three totally different computers, each with a totally different audio interface (each using a different bus to talk to the machine). The number of variables introduced as a result makes all their conclusions invalid before they generated the first impulse
2) Not only do they use dissimilar hardware for each platform they are using different software (and even when using the same software they use different versions of software). By not using consistent software testing methodologies accross the platforms all their conclusions are invalid.
Weak Knowledge
1) Assuming that there should be Zero samples of latency when audio is passing through a digital interface is plain wrong
2) "Proving" that there is no bandwidth limitation in the manner they did doesn't actually prove what they say it does. That they're using SP/DIF will have influence on their results due to bandwidth restrictions...
3) Not understanding how their test apparatus might introduce unexpected results and take steps to ensure that isn't the case.
There's a whole pile more wrong with this paper, but the testing methodology alone is enough to invalidate anything but 3 sets of distinct measurements of 3 uncorrellated systems.
What WOULD be in an interesting paper is take a Mac Pro (Reference Intel Architecture) and test it with a selection of interfaces under all three OSes (Using boot camp for native access to hardware).
Firstly, for tagging, either read in the tags as you rip your CDs (most reliable method), or if you are tagging after the fact then I agree that there seems no superb solution on any OS. I think I used Jaikoz recently for re-touching up some Flac files and it seemed ok?
My current pain is getting high quality cover art for each CD without scanning in covers... Lots of apps do the easy ones, but getting a good interface which handles the more obscure stuff, or where there are multiple matches etc is quite tricky...
Secondly I agree that there doesn't seem to be a public domain HDCD decoder available (check ffmpeg to be 100% sure?). Wikipedia suggests that there may also be a Foobar plugin which decodes hdcd to 20 bit? I believe Microsoft bought some/all of the patents and I guess no one is raising their head above the parapet here? The patents should describe how to decode everything though - anyone want a crack at it?
OK, to address your rant:
See, you are misquoting and arguing a completely different issue again?
Look, you claimed that a 9632 was "midfi" and I countered that I was of the opinion that DACs vary, but are they really the weakest link in the chain? At no point did I claim the 9632 is a "top audio multichannel interface" (But I will go on record now and claim it's a "decent interface" - and qualify that as "others are better, but this one is good enough")
Personally I don't use the HDSP mixer to control my card, I just use the normal alsa mixer as far as possible and setup the matrix mixer using a boot script. This works well for my needs.
I would definitely concede that a pro-audio worker would want a nicer mixer than the HDSP-Mixer though... The issues don't seem hard to fix though- I guess no one has needed these changes enough to fix the current minor gremlins?
So to return to what I actually said. Are you telling me that if I go find these threads then I will hear opinions that the 9632 is a positively *bad* sounding DAC? As opposed to "it can be made better"?
I agreed previously that any DAC can be "improved" further, but I challenged you to find me a DAC which has substantial measured performance, but sounds positively poor? By this I mean that a bunch of hifi heads can sit around talking about whether the Lynx, RME, Benchmark DAC or whatever have more "grain" or more "veils lifted" or whatever, but functionally they are all excellent starting points and simply vary in excellence?
Look at the facts though:
- All decent DACs are going to have >90dB SNR, probably a significant fraction of that being extremely linear and near zero dB shift from flat in the audio range?
- I *believe* that the human ear is sensitive enough to hear even 0.1dB change in freq response that might occur due to changing DAC's, cables or whatever
- BUT your transducers measure +/- 6dB or more in terms of in-room response and have huge phase errors, perhaps slap echos and other reverberant reflections barely into double digit dB down on the main impulse....
- I *STILL* believe you can hear a tiny change in DAC on top of all that junk that the transducer has added, human ears are INCREDIBLY sensitive and clever apparatus, but my point is .... work on the transducers first!
(I'm not sure why it doesn't quote my quote)
I don't understand your response here? A FIR filter is simply achieved by multiplying the last "N" audio samples by a fixed set of constants (your filter) and adding up the results. Call it an array multiply if you like.
So a trivial example would be a filter which is simply [1.0]. You then filter the audio by multiplying every value by 1.0. (My example). Are you seriously saying that you think this reduces sound quality?
Any physical crossover (say in your speakers) can be implemented to arbitrary accuracy using a FIR filter. However, the physical analogue crossover will not actually behave as per your calculations say it should since physical components tend to fail to match their specifications exactly. On the other hand the FIR crossovers will *perfectly* match their specifications (give or take the numerical accuracy that you choose). As such a FIR based crossover will always give a more "accurate" result than an analogue physical crossover. (For many people the digital crossover is also easier to "build" and experiment with and therefore can be a good starting point even if you later revert to an analogue crossover for final build)
What losses are these? You see you keep making handwaving arguments but never providing references so that your arguments can be proved or disproved?
A FIR filter is not a "thing", its just a name for a particular form of multiplying numbers together and adding them up. It gets boring to say "array multiply the last N samples by this array of N constants, add up the total and that's your new sample", so people call that bit of maths "A FIR Filter"
Mathematics is provable, analysable and disputable. Pick your problem and raise it. Don't just handwave.
The main "issues" with multiplication on a computer is that it needs to be done to a finite accuracy and this means a priori that we know the answer is "incorrect" at some level. However, careful analysis of the problem shows that our rounding errors can be made arbitrarily small and for example in this case it's *reasonably difficult* to get yourself into trouble.
For anyone who skimmed over that - basically I'm saying that you need to round off your numbers at some point. You can do your maths to 60 decimal places, 100 decimal places, 1000 decimal places, but you need to round your answers. However, the computer will usually perform your calculations at a level leading to absolutely tiny rounding errors as far as us humans are concerned (any non IT folks realise just how big 2^64 actually is?)
Are you saying that these quotes I'm attributing to you are not things you said? They are easily seen to be things you said simply by refering back to your previous post?
Again handwaving - spit it out - what are these "more than obvious" intentions?
To be clear - my intentions are to dispel some of the handwaving arguments that you are making. I apologise because this is coming over as a personal attack when it's not meant to be - in fact I think a lot of what you are doing is great and should be encouraged.
What you need to focus on is that you often have a great and interesting point (say that the 9632 can be improved), but then you tie it to an unnecessary and unrelated statement (such as "the 9632 is midfi") which then warrants people ending up apparently attacking your whole argument when they don't really wish to
Just keep your points succinct and keep your focus narrow. Don't start inventing stuff about distributions and alsa workings and mathematics and other stuff that aren't your main focus. Keep on track and don't get drawn off-topic. You don't need to get people to think you are an expert on *everything* to earn respect for the stuff you obviously do know lots about? Stick to your core competency!
Good luck - keep up the good work?!
Ed W
My current pain is getting high quality cover art for each CD without scanning in covers... Lots of apps do the easy ones, but getting a good interface which handles the more obscure stuff, or where there are multiple matches etc is quite tricky...
Secondly I agree that there doesn't seem to be a public domain HDCD decoder available (check ffmpeg to be 100% sure?). Wikipedia suggests that there may also be a Foobar plugin which decodes hdcd to 20 bit? I believe Microsoft bought some/all of the patents and I guess no one is raising their head above the parapet here? The patents should describe how to decode everything though - anyone want a crack at it?
OK, to address your rant:
Some examples:
He is trying to sell a HDSP9632 as a top audio multichannel interface by just talking about
very convincing argument - probably copied from the marketing leaflet - no, no, no way, that can't be the case, because RME would have serious difficulties to explain how they'd measure "performance".
See, you are misquoting and arguing a completely different issue again?
Look, you claimed that a 9632 was "midfi" and I countered that I was of the opinion that DACs vary, but are they really the weakest link in the chain? At no point did I claim the 9632 is a "top audio multichannel interface" (But I will go on record now and claim it's a "decent interface" - and qualify that as "others are better, but this one is good enough")
Well the card was released about then? Whats the problem?Probably that's possible with RME-HW related Alsa tools such as HDSP-Mixer which have been updated just recently in "2003". Pretty impressive.
Personally I don't use the HDSP mixer to control my card, I just use the normal alsa mixer as far as possible and setup the matrix mixer using a boot script. This works well for my needs.
I would definitely concede that a pro-audio worker would want a nicer mixer than the HDSP-Mixer though... The issues don't seem hard to fix though- I guess no one has needed these changes enough to fix the current minor gremlins?
For HW related DIY and modification discussions , in case you are interested to learn a bit more about it, I'd like to refer you to the digital section of DIY-Audio. There you'll quickly learn what's wrong with your RME ( start with the PS and power conditions inside a PC, followed by the opamps and output stage and don't to forget to read about the impact of extensive digital attenuation. .
So to return to what I actually said. Are you telling me that if I go find these threads then I will hear opinions that the 9632 is a positively *bad* sounding DAC? As opposed to "it can be made better"?
I agreed previously that any DAC can be "improved" further, but I challenged you to find me a DAC which has substantial measured performance, but sounds positively poor? By this I mean that a bunch of hifi heads can sit around talking about whether the Lynx, RME, Benchmark DAC or whatever have more "grain" or more "veils lifted" or whatever, but functionally they are all excellent starting points and simply vary in excellence?
Look at the facts though:
- All decent DACs are going to have >90dB SNR, probably a significant fraction of that being extremely linear and near zero dB shift from flat in the audio range?
- I *believe* that the human ear is sensitive enough to hear even 0.1dB change in freq response that might occur due to changing DAC's, cables or whatever
- BUT your transducers measure +/- 6dB or more in terms of in-room response and have huge phase errors, perhaps slap echos and other reverberant reflections barely into double digit dB down on the main impulse....
- I *STILL* believe you can hear a tiny change in DAC on top of all that junk that the transducer has added, human ears are INCREDIBLY sensitive and clever apparatus, but my point is .... work on the transducers first!
Anybody around who'd be able to figure out any logic on that response?
Very funny logic. This is getting ridiculous.
(I'm not sure why it doesn't quote my quote)
I don't understand your response here? A FIR filter is simply achieved by multiplying the last "N" audio samples by a fixed set of constants (your filter) and adding up the results. Call it an array multiply if you like.
So a trivial example would be a filter which is simply [1.0]. You then filter the audio by multiplying every value by 1.0. (My example). Are you seriously saying that you think this reduces sound quality?
Any physical crossover (say in your speakers) can be implemented to arbitrary accuracy using a FIR filter. However, the physical analogue crossover will not actually behave as per your calculations say it should since physical components tend to fail to match their specifications exactly. On the other hand the FIR crossovers will *perfectly* match their specifications (give or take the numerical accuracy that you choose). As such a FIR based crossover will always give a more "accurate" result than an analogue physical crossover. (For many people the digital crossover is also easier to "build" and experiment with and therefore can be a good starting point even if you later revert to an analogue crossover for final build)
What losses are these? You see you keep making handwaving arguments but never providing references so that your arguments can be proved or disproved?
A FIR filter is not a "thing", its just a name for a particular form of multiplying numbers together and adding them up. It gets boring to say "array multiply the last N samples by this array of N constants, add up the total and that's your new sample", so people call that bit of maths "A FIR Filter"
Mathematics is provable, analysable and disputable. Pick your problem and raise it. Don't just handwave.
The main "issues" with multiplication on a computer is that it needs to be done to a finite accuracy and this means a priori that we know the answer is "incorrect" at some level. However, careful analysis of the problem shows that our rounding errors can be made arbitrarily small and for example in this case it's *reasonably difficult* to get yourself into trouble.
For anyone who skimmed over that - basically I'm saying that you need to round off your numbers at some point. You can do your maths to 60 decimal places, 100 decimal places, 1000 decimal places, but you need to round your answers. However, the computer will usually perform your calculations at a level leading to absolutely tiny rounding errors as far as us humans are concerned (any non IT folks realise just how big 2^64 actually is?)
Are you saying that these quotes I'm attributing to you are not things you said? They are easily seen to be things you said simply by refering back to your previous post?
Again handwaving - spit it out - what are these "more than obvious" intentions?
To be clear - my intentions are to dispel some of the handwaving arguments that you are making. I apologise because this is coming over as a personal attack when it's not meant to be - in fact I think a lot of what you are doing is great and should be encouraged.
What you need to focus on is that you often have a great and interesting point (say that the 9632 can be improved), but then you tie it to an unnecessary and unrelated statement (such as "the 9632 is midfi") which then warrants people ending up apparently attacking your whole argument when they don't really wish to
Just keep your points succinct and keep your focus narrow. Don't start inventing stuff about distributions and alsa workings and mathematics and other stuff that aren't your main focus. Keep on track and don't get drawn off-topic. You don't need to get people to think you are an expert on *everything* to earn respect for the stuff you obviously do know lots about? Stick to your core competency!
Good luck - keep up the good work?!
Ed W
Soundcheck,
I've read your effort in a dedicated Audio LINUX setup.
I was done to try something myself however i'm a 100% Newbee in Linux.
So, first, i'm really desparate to see that your wiki has desapered, secondly i'm perplex to waiste my time when i see that you have moved to the Touch that you have moded with the same phylosophy that my XP computer has been tuned (as per Cics recomendation).
Do you think that your modded Touch is better than what you have ever acheived with any of your Linux setup ?
I personnaly don't know anything about Linux but would like to follow your trail for pro bably similar conviction on small linux that loads from RAM or flash card.
Here is my personnal experience :
I build an audio computer as per Cics recommenation (under XP) using passive cooling, fast Ram, Hybrid PSU, and i tried the same config with Cplay/CMP, Andy's ASIO Minimalist Memory Player, and finally Headless with Squeezebox emulating software (SqueezeSlave ASIO).
Now i would like to go one step furthe with a minialist Linux distro using Realtime and killing as much daemon as possible still using Squeezeslave (getting the streamed wav over the intranet and sending it to the soundcard)
I was running a hifi shop for the past ten years, i had then the opportunity to try a lot of hi-end stuff.
I have tried regular sueezebox, receiver, Touch along with a good but not state of the art linear PSU and Transporter back when it was only 96 Khz compatible. All these have been tested with different DAC (SPDIF or in case of transporter AES)
None of these setup could mach a good CD player with same DAC.
For instance Transporter with good Power cable with Siltech Golden Ridge AES cable with Rymio DAP 777 could not match CEC TL51 with same cable and same DAC.
However there was potential to the Logitech stuff (best of all money wise is TOUCH)
So back at the time of my trials with Transporter i decided to build a computer based on similar principals as Squeezebox, namely a Cics recommended configuration as described ealier, i tried it with a RME digi 24/96, a Juli@ and a Marian souncard.
Both Juli@ and RME could be powered by their own PSU, not the Marian.
Juli@ was not very good, i might try tapping I2S and adding a good clok as i beleive thats its weakness.
RME and MARIAN TRACE D4 were excellent with same AES cable and same Reymio DAC it was better sounding than the best CD player i had namely CEC TL0x along with same AES cable and same DAC.
But Cplay is not that fun to remote than a squeezebox, no cover, limited tags, etc...
So i decided to try on the same machine SqueezeSlave ASIO (there is a version that support ASIO) and i did some batch to run the full system from ram, fixing prioties, and affinity for almost each of the 11 or 12 process (audio is handled by one core, the other process are handled by the other core, audio has highest priority, other process lowest)
Soundwise, tbh i have not had the ability to test it on the same setup, i have tested it on a less resolving setup, so it is difficult to be precise, however it seems not far from Cplay with the comfort of tne nice web interface and the tags, etc...
By the way i use dBPowramp instead of EAC, same quality, plus tag, cover even for wav files.
So reading different post i wanted to do pretty much the same under linux to have even more flexibility (if possible) and realtime.
By the way my windows XP is so lite, it is less than 1GB, it starts from a 2GB SATA Flash Card in a few seconds.
So knowing nothing about linux, having spent countless hours on XP, i want to be sure it is worth th effort and i want the finest and easiest distro to acheive that goal.
But before i should first try to hack a Touch as per your recommendation and listen how it compares to my setup.
Please advise and if possible send me your las wiki.
Best regards, and thank you for your efforts.
Jean
I've read your effort in a dedicated Audio LINUX setup.
I was done to try something myself however i'm a 100% Newbee in Linux.
So, first, i'm really desparate to see that your wiki has desapered, secondly i'm perplex to waiste my time when i see that you have moved to the Touch that you have moded with the same phylosophy that my XP computer has been tuned (as per Cics recomendation).
Do you think that your modded Touch is better than what you have ever acheived with any of your Linux setup ?
I personnaly don't know anything about Linux but would like to follow your trail for pro bably similar conviction on small linux that loads from RAM or flash card.
Here is my personnal experience :
I build an audio computer as per Cics recommenation (under XP) using passive cooling, fast Ram, Hybrid PSU, and i tried the same config with Cplay/CMP, Andy's ASIO Minimalist Memory Player, and finally Headless with Squeezebox emulating software (SqueezeSlave ASIO).
Now i would like to go one step furthe with a minialist Linux distro using Realtime and killing as much daemon as possible still using Squeezeslave (getting the streamed wav over the intranet and sending it to the soundcard)
I was running a hifi shop for the past ten years, i had then the opportunity to try a lot of hi-end stuff.
I have tried regular sueezebox, receiver, Touch along with a good but not state of the art linear PSU and Transporter back when it was only 96 Khz compatible. All these have been tested with different DAC (SPDIF or in case of transporter AES)
None of these setup could mach a good CD player with same DAC.
For instance Transporter with good Power cable with Siltech Golden Ridge AES cable with Rymio DAP 777 could not match CEC TL51 with same cable and same DAC.
However there was potential to the Logitech stuff (best of all money wise is TOUCH)
So back at the time of my trials with Transporter i decided to build a computer based on similar principals as Squeezebox, namely a Cics recommended configuration as described ealier, i tried it with a RME digi 24/96, a Juli@ and a Marian souncard.
Both Juli@ and RME could be powered by their own PSU, not the Marian.
Juli@ was not very good, i might try tapping I2S and adding a good clok as i beleive thats its weakness.
RME and MARIAN TRACE D4 were excellent with same AES cable and same Reymio DAC it was better sounding than the best CD player i had namely CEC TL0x along with same AES cable and same DAC.
But Cplay is not that fun to remote than a squeezebox, no cover, limited tags, etc...
So i decided to try on the same machine SqueezeSlave ASIO (there is a version that support ASIO) and i did some batch to run the full system from ram, fixing prioties, and affinity for almost each of the 11 or 12 process (audio is handled by one core, the other process are handled by the other core, audio has highest priority, other process lowest)
Soundwise, tbh i have not had the ability to test it on the same setup, i have tested it on a less resolving setup, so it is difficult to be precise, however it seems not far from Cplay with the comfort of tne nice web interface and the tags, etc...
By the way i use dBPowramp instead of EAC, same quality, plus tag, cover even for wav files.
So reading different post i wanted to do pretty much the same under linux to have even more flexibility (if possible) and realtime.
By the way my windows XP is so lite, it is less than 1GB, it starts from a 2GB SATA Flash Card in a few seconds.
So knowing nothing about linux, having spent countless hours on XP, i want to be sure it is worth th effort and i want the finest and easiest distro to acheive that goal.
But before i should first try to hack a Touch as per your recommendation and listen how it compares to my setup.
Please advise and if possible send me your las wiki.
Best regards, and thank you for your efforts.
Jean
clock? I thing the clock of the Juli@ is very good, it uses two quartzes for both multiples of 44.1KHz and 48KHz. Out there it is considered one of the best options for stereo digital output.
oh! that's an achievement! CEC TL0X is one of the best machines on the market. I had an experience listening to it paired with Audionote DAC5... real life man!
Anyway, I am a linux guy because I use it for work and I am more familiar with it expecially for doing backups and script based stuffs. I guess there will be little difference between linux and win boxes if well configured. One problem with linux is drivers availability.
Best
P
Please, don't worry about whether it's Windows or Linux. Apart from the fact that some audio paths through both operating systems can damage audio quality by say inappropriate resampling/quantising, other than that the software just feeds samples to a large buffer on the DAC. Both operating systems should feed exactly the same samples into the same large buffer, where they will be reclocked and handled by the DAC without further intervention from the computer
As such the choice of Windows/Linux is really down to which offers the software you need and also which is simplest to configure to avoid unnecessary resampling/quantising. For example in the past, with XP it was reasonably difficult to avoid all audio being resampled by a low quality resampler and you needed tricks such as using ASIO drivers with specific audio software. However, I *believe* that with Windows 7 the audio mixer is vastly improved and subject to some caveats you can use any audio application?
I personally use Linux because it's more familiar to me and simpler for me to configure the way I wish. I doubt that it produces different audio out of the soundcard if I were to boot Windows on it (caveat that we avoid damaging resampling/quantising in both cases)
I guess we can figure out some reasons why one operating system might cause ever so slightly different results, but we would be right down at the level of: one OS causes fractionally lower/higher CPU usage which causes fractionally more/less ripple on the powerlines, which in turn due to poor powersupply design on the audio card isn't adequately filtered and causes some perceptible difference to the DAC output... However, as you can see we are into pretty esoteric stuff here
I think people tend to get hung up on the wrong things when looking at PC based audio. Dont worry too much about the software, (bar that it actually destroys quality - and to be fair many audio applications aren't optimal)
Good luck
As such the choice of Windows/Linux is really down to which offers the software you need and also which is simplest to configure to avoid unnecessary resampling/quantising. For example in the past, with XP it was reasonably difficult to avoid all audio being resampled by a low quality resampler and you needed tricks such as using ASIO drivers with specific audio software. However, I *believe* that with Windows 7 the audio mixer is vastly improved and subject to some caveats you can use any audio application?
I personally use Linux because it's more familiar to me and simpler for me to configure the way I wish. I doubt that it produces different audio out of the soundcard if I were to boot Windows on it (caveat that we avoid damaging resampling/quantising in both cases)
I guess we can figure out some reasons why one operating system might cause ever so slightly different results, but we would be right down at the level of: one OS causes fractionally lower/higher CPU usage which causes fractionally more/less ripple on the powerlines, which in turn due to poor powersupply design on the audio card isn't adequately filtered and causes some perceptible difference to the DAC output... However, as you can see we are into pretty esoteric stuff here
I think people tend to get hung up on the wrong things when looking at PC based audio. Dont worry too much about the software, (bar that it actually destroys quality - and to be fair many audio applications aren't optimal)
Good luck
@bidule
We tried a CPLAY/CMP2 setup with ESI Juli and I2S-out feeding a TP Buffalo Sabre. All devices were highly modded. The sound was quite good.
I installed my Linux stuff on the same machine. My Linux setup sounded even better then CPLAY.
(I still run my 1543 USB DAC with my Linux setup btw.)
I'd consider a tweaked Touch the device of choice compared to above PC setups.
In US it sells on certain occasions in the 180$ range already. I feed SPDIF into a TP Sabre 32. This price/performance ratio will be hard to beat.
There are some things bugging me about the Touch though:
1. You can't turn the monitor off by SW
2. Pretty old Linux rt-Kernel and Alsa
3. No access to kernel config
4. Wlan operation is IMO a No Go.
5. 24/96 HiRez gets the device quickly to its limits at different corners
6. The bigger your collection - database handling will slow down
Wiki:
I thought about rewriting the Wiki. Though with the Touch in operation my priorities shifted from an 80% technology and software focus to an 80% music focus recently.
Converting/Tagging: BTW all my .wav files are now converted to flac and properly tagged (65hours of net processing time by a script)
I continue to use puddletag for tagging under Linux.
The latest puddletag SVN build 235 - I consider quite useful. Still there are some weaknesses with that program.
Cheers
We tried a CPLAY/CMP2 setup with ESI Juli and I2S-out feeding a TP Buffalo Sabre. All devices were highly modded. The sound was quite good.
I installed my Linux stuff on the same machine. My Linux setup sounded even better then CPLAY.
(I still run my 1543 USB DAC with my Linux setup btw.)
I'd consider a tweaked Touch the device of choice compared to above PC setups.
In US it sells on certain occasions in the 180$ range already. I feed SPDIF into a TP Sabre 32. This price/performance ratio will be hard to beat.
There are some things bugging me about the Touch though:
1. You can't turn the monitor off by SW
2. Pretty old Linux rt-Kernel and Alsa
3. No access to kernel config
4. Wlan operation is IMO a No Go.
5. 24/96 HiRez gets the device quickly to its limits at different corners
6. The bigger your collection - database handling will slow down
Wiki:
I thought about rewriting the Wiki. Though with the Touch in operation my priorities shifted from an 80% technology and software focus to an 80% music focus recently.
Converting/Tagging: BTW all my .wav files are now converted to flac and properly tagged (65hours of net processing time by a script)
I continue to use puddletag for tagging under Linux.
The latest puddletag SVN build 235 - I consider quite useful. Still there are some weaknesses with that program.
Cheers
Last edited:
A SB seems like a fine center for a good audio system to me (not disputing that there is better to be had either).
Did you also look at "Inguz" audio, eg some notes here:
User:Hpyle - DRC
To my thinking, the transducers are nearly always the biggest influence on sound quality and it's interesting that you can trade a little bit of off-axis performance for better on-axis performance if you use some carefully designed digital filters. (Hifi nuts are usually comfortable with narrow sweet spots, so this doesn't seem like anything new)
P.S. Where is this wiki that people keep talking about?
Did you also look at "Inguz" audio, eg some notes here:
User:Hpyle - DRC
To my thinking, the transducers are nearly always the biggest influence on sound quality and it's interesting that you can trade a little bit of off-axis performance for better on-axis performance if you use some carefully designed digital filters. (Hifi nuts are usually comfortable with narrow sweet spots, so this doesn't seem like anything new)
P.S. Where is this wiki that people keep talking about?
Hi Bob.
I am running the predecessor model (Robert Bastani's personal protoytpes) of these:
Bastanis Appollo
In US these are sold over here:
Apollo at Bauls-Audio
You can also find a nice review about the next lower model called Prometheus MK II at 6moons.
I had been able to acquire the fullrange and tweeter part of that Apollo speaker. I built my own Linkwitz/Ripol style woofer dipoles based on 4 pcs. BD-Design BD 15. Since those Ripol style woofers are protected by a patent, Bastani can not build them by himself. I consider the Ripol structure clearly better then his own woofers. It perfectly mates the upper end dipole.
The fullrange driver runs without any crossover and the tweeter got only a single 1uf cap (1st order HP @ 9.5kHz) in front of it. Here I am using the best cap I could find - a 1uf - Thel Glimmer.X Silver Mica. Neutrality, speed and level of detail I consider extraordinary. It clearly beats e.g. Mundorf Silver/Gold(/Oil), which I had running prior to the Thel's.
I also improved on the horn in front of the tweeter ( which runs as a dipole too!) . I am now using a Phio Horn. It helped a lot on making the sound more coherent and clean in the upper range. The "micro"-dynamics develop a 3Dimensionality with the absence of a the horn typical side-effects. This makes this setup IMO very special.
I do also separate the cable runs (I use Dope-Sounds Voodoo Cable - solid core silver), which are connected right to the driver terminals (to avoid any binding posts and cable cuts in between!!).
Since 4 years by now I am more then happy with this setup.
To the others: Sorry for being off-topic with this.
Cheers
Last edited:
Hi soundcheck
Please could you elaborate on the weaknesses you refer to above. We're always keen on constructive feedback to help improve puddletag. btw, if you've not checked out the latest build, you'd do well to do so, there's been quite a lot of functionality added including automated masstagging of multiple albums using multiple tag sources.
It's you again. You're late.
Weaknesses: Please have a look at AA or your own forum to avoid redundancies.
Looking forward to PD 1.00.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.