This is a forum for people who "measure", not a forum for voodoo magic.
Please provide your evidence that either:
a) the software is mangling the "bits", or
b) the DAC is sounding different depending how you feed an identical set of bits to it
There is little point simply doing voodoo magic where clocking the processor 2/3 the speed sounds better or feeding the same bitstream with application A "sounds better" than using application B. Find the source of the problem and fix it rather than trying to wave a magic wand
Measure, measure, measure (not with your ears, use something objective)
Please provide your evidence that either:
a) the software is mangling the "bits", or
b) the DAC is sounding different depending how you feed an identical set of bits to it
There is little point simply doing voodoo magic where clocking the processor 2/3 the speed sounds better or feeding the same bitstream with application A "sounds better" than using application B. Find the source of the problem and fix it rather than trying to wave a magic wand
Measure, measure, measure (not with your ears, use something objective)
ewildgoose said:
I expected something like that. If you guys run out of ideas or arguments, you just bring
up the "measurement" story.
I can't afford mega-buck equipment. Do you expect me to purchase a >20k analyser to proof that a 100$ DAC sounds 5% better with ecasound than MPD. On what planet
are you living?
Man - I just type a command and listen. That's about it - period.
I've seen many of these so called "gurus" who actually failed on delivering measurements from inside a PC. I havn't seen very much of these (relevant) measurments at all.
I'm agree with ewildgoose - if you hear difference, just fix bugs in used sw. I'm not too far from Linux audio software (being QLoud author), or from listening to music (being listening to jazz 24/7). Probably, I have tried almost all players/engines under Linux (at least those ones which are in the Gentoo portage) and have not noticed any formal or emotional differences during all these years (BTW, RME HDSP 9632 is in use). Of course, I'm not saying about cases when this or that sw has a bug.
Ok, I see, there is another opportunity - probably I'm deaf... Well, also have not noticed this fact
Well, there are some playing back problems in the other (m$) camp - every piece of sw audio chain tries to do something "smart" with a sound. But here (Linux) we live in lucky world, don't we?
Ok, I see, there is another opportunity - probably I'm deaf... Well, also have not noticed this fact
Well, there are some playing back problems in the other (m$) camp - every piece of sw audio chain tries to do something "smart" with a sound. But here (Linux) we live in lucky world, don't we?
soundcheck said:
This sounds like the old - the world is flat - I refuse to believe it or go find some evidence either way
soundcheck said:
Which comes back to my other point - perhaps you are on the wrong forum. Quite clearly recording the digital output of a sound card by feeding it back into the digital input of (same or other) soundcard is kind of basic level for someone who is arguing this subject
I was actually expecting you to be at least a bit higher level and at least claim that they didn't match because there was random amounts of silence at the beginning or something, but failing to grasp how to record the digital output of your own card is well below what I was expecting...
There are plenty other ways you could capture the digital output. The above seems like the simplest, but I doubt too many here own 20K analysers either - this is a DIY forum... You are just being silly...
soundcheck said:
Oh well, I'm just one of those simpletons who has actually tried to test this... You can find my "rec_imp" application at http://www.duffroomcorrection.com - this sends an impulse to the output and records the input and if you do a loopback then you should get a dirac pulse if the loop is perfect. Curiously the offset of the pulse will also measure the loop delay from output to input (about 23 odd samples on my RME 9632 from memory).
It talks to quite a few output drivers so you can even measure (and see) that windows drivers sometimes mess up the signal instead of passing it through unaltered - also you can see when resampling is done badly and breaks thing
If you don't understand the above then at least go read up before responding - I hardly think it's sensible to be arguing voodoo magic if you lack even a baseline performance to objectively measure against.
If you measure then it's science - if you guess then it's just guesswork...
soundcheck said:
The problem is that listening is not an engineering process. There are no standard (measurable in any known units) for sound quality and vice versa. Additionally, sound quality perception is very personal and is subject of taste (and taste is not subject of discussion).
I think we should clearly distinguish personal listening impression from measurements with oscilloscope or any other industrial instrument. These are very different matters, and collision between them is useless waste of time.
Can two audio players sound different on the same PC system ??? If course they can because there might be some code built-in which modify/tweak audio source info for whatever reason.
But if they both send raw bits sound will be indistinguishable in blind tests.
Anyway, coming back to the core questions
- Jack seems to work reasonably reliably and has a fairly small overhead. However, it's network capabilities are a bit limited (cross platform). Also, it's not straightforward to dynamically start Jack at different sample rates (and startup a network of plugins at the same time, eg brutefir).
- It would be desirable to at least have the option to separate audio generation from the machine which consumes it.
- Pulse audio looks like the best future bet on an audio server which is cross platform, handles multiple output devices and has some ability to sync multiple remote network connected outputs.
- Anyone tried using pulse audio as the audio server with Jack as the output device?
I currently do everything on one machine so don't yet have a need for this - however, if I went dual box I would also like somthing like a Mac Mini as the audio server, which in turn means that I need to find a good firewire audio card which can do 8+ analogue outputs. The Echo Audio looks on paper to be one of the few supported devices which might work out. Anyone tried one of these?
http://www.echoaudio.com/Products/FireWire/AudioFire8/index.php
Any other ways to slice this one?
- Jack seems to work reasonably reliably and has a fairly small overhead. However, it's network capabilities are a bit limited (cross platform). Also, it's not straightforward to dynamically start Jack at different sample rates (and startup a network of plugins at the same time, eg brutefir).
- It would be desirable to at least have the option to separate audio generation from the machine which consumes it.
- Pulse audio looks like the best future bet on an audio server which is cross platform, handles multiple output devices and has some ability to sync multiple remote network connected outputs.
- Anyone tried using pulse audio as the audio server with Jack as the output device?
I currently do everything on one machine so don't yet have a need for this - however, if I went dual box I would also like somthing like a Mac Mini as the audio server, which in turn means that I need to find a good firewire audio card which can do 8+ analogue outputs. The Echo Audio looks on paper to be one of the few supported devices which might work out. Anyone tried one of these?
http://www.echoaudio.com/Products/FireWire/AudioFire8/index.php
Any other ways to slice this one?
LinuksGuru said:
Hello LinuksGuru,
Both your quoted statements are wrong. The whole discussion above is for me a clear example of die-hard technicians against persons that are interested in music. In the 1970's I met many technicians that started to laugh very loud if I said that I could hear differences between cables. In the early 1980's lots of technicians told us that CD's are perfect.
Now we encounter technicians that do not hear the difference between one player and another. If you have lousy equipment and you are not interested in the details of the music then you can claim this. For me such a statement has no value.
I know the complexities of the sound of high quality acoustical instruments. I can understand why musicians spend a fortune on an instrument that they like. My goal is to get as much as possible of this sound from my music system within a limited budget. And I do hear lots of differences between players on my PC. Even with the same player used in a graphics terminal or in recovery mode.
I would like to know the technical/scientific reasons for these differences. But in the mean time I am very happy with the music that I can enjoy every evening. Almost three months ago I got the opportunity to swap Brutefir (brutus) against Ecasound (ecasx), (thanks to Soundcheck !). A clear example of how sound quality can be improved at no cost.
Someone else in this thread said "I do not trust my ears". Well, if you do not trust them, what do you trust?
Kind regards,
Eddie
I think he just misphrased his statement. Remember that he is talking about a situation with the *same* sound card being supplied *exactly the same* bitstream, only the name of the process supplying the data is changed - this seems to leave only very small reasons for the sound to be different in each case
Actually I *do* agree that it *could* sound different. Early in this thread someone pointed out that many cards have only mediocre PSRR and it's entirely possible that one program might inadvertently cause more RFI from the processor than some other program
However, my point was that science (not guesswork) could determine exactly where the difference was coming from. After all it's also possible that one program is mangling the audio data - if this is so then the two programs mentioned are opensource and can be fixed. On the other hand if the bitstream is measured and found to be exact then the audio card can be examined and sensible science applied to find the problem.
The problem with the voodoo approach is that you are trying to patch up one unmeasurable effect with another one. For example if it's some kind of powersupply noise getting into the card then the voodoo approach is to try loads of software players and pick one which apparently works best. The science approach is to improve the quality of the PSU...
The problem with the voodoo approach is that your results will perhaps not apply to me because my equipment may have different weaknesses, or be stimulated differently. The benefit of the science approach and fixing the PSU works everywhere...
Don't get me wrong - a few years back I used to dabble with cables and I certainly believe I can hear differences between them. However, now I view that as a problem with the equipment being "broken" if it doesn't like a certain cable and prefer to try and fix the equipment rather than go down the route of endless swapping of cables and other voodoo...
By the way - when you say you swap Brutefir for Ecasound - how are you doing your convolution if you dropped brutefir? Do you use some kind of plugin filter? If this is explained in another post then please just send the link?
Good luck
Actually I *do* agree that it *could* sound different. Early in this thread someone pointed out that many cards have only mediocre PSRR and it's entirely possible that one program might inadvertently cause more RFI from the processor than some other program
However, my point was that science (not guesswork) could determine exactly where the difference was coming from. After all it's also possible that one program is mangling the audio data - if this is so then the two programs mentioned are opensource and can be fixed. On the other hand if the bitstream is measured and found to be exact then the audio card can be examined and sensible science applied to find the problem.
The problem with the voodoo approach is that you are trying to patch up one unmeasurable effect with another one. For example if it's some kind of powersupply noise getting into the card then the voodoo approach is to try loads of software players and pick one which apparently works best. The science approach is to improve the quality of the PSU...
The problem with the voodoo approach is that your results will perhaps not apply to me because my equipment may have different weaknesses, or be stimulated differently. The benefit of the science approach and fixing the PSU works everywhere...
Don't get me wrong - a few years back I used to dabble with cables and I certainly believe I can hear differences between them. However, now I view that as a problem with the equipment being "broken" if it doesn't like a certain cable and prefer to try and fix the equipment rather than go down the route of endless swapping of cables and other voodoo...
By the way - when you say you swap Brutefir for Ecasound - how are you doing your convolution if you dropped brutefir? Do you use some kind of plugin filter? If this is explained in another post then please just send the link?
Good luck
By the way the "I don't trust my ears" you might be taking a bit literally
I agree that some stuff sounds "better" to me. However, it can be for all kinds of reasons including what mood I am in.
I guess I have two competing goals. Sometimes I just want to enjoy some music. At other times I am trying to build the "best" system that I can. In the case of the latter it's helpful to use objective and repeatable benchmarks as far as possible
However, definitely "ears" are very subjective and I have definitely fooled myself on many occasions. Amazing even how a few tenths of a dB can distort the perception of which equipment is "best". I would definitely recommend trying some ABX testing on any stuff you are "sure about". It's quite amazing how the "clear" differences tend to evaporate (sometimes)!
Good luck
Ed
I agree that some stuff sounds "better" to me. However, it can be for all kinds of reasons including what mood I am in.
I guess I have two competing goals. Sometimes I just want to enjoy some music. At other times I am trying to build the "best" system that I can. In the case of the latter it's helpful to use objective and repeatable benchmarks as far as possible
However, definitely "ears" are very subjective and I have definitely fooled myself on many occasions. Amazing even how a few tenths of a dB can distort the perception of which equipment is "best". I would definitely recommend trying some ABX testing on any stuff you are "sure about". It's quite amazing how the "clear" differences tend to evaporate (sometimes)!
Good luck
Ed
EddieV said:
1) If so, can you distinguish in blind tests for example 10 different audio interconnect cables by brands and models ???
2) For early 1980 CDs were really best available mainstream media, there were no mainstream HD Audio or something comparable in commodity market.
What does it mean trust ears? Ears is not universal measurement instrument. Something very good for me may be bad for someone else. For example, I like tube sound, while others simply cannot stomach it at all. So, is tube sound good or bad, hi-fi or low-fi?
Do people listening cables or capacitors ever realized that acoustic of room and placement of speakers within it contributes incomparably more degree of sound perception then different decent quality DACs, capacitors, or cables ???
When people subjectively comparing different components of audio system setup, they simply do not realize the fact - they are speaking about that particular component and in that particular system in that particular room with all its acoustic characteristics, and it does not automatically correlates to the whole universe.
That's why measurements and numbers are so important. Yes, they do not tell the whole story about perception by certain person(s). But poorly designed component with high level of TIM, noise, high degree of non-linearity will not sound good in any system.
http://slashdot.org/article.pl?sid=09/03/11/153205
Young People Prefer "Sizzle Sounds" of MP3 Format
"Jonathan Berger, a professor of music at Stanford, tests his incoming students each year by having them listen to a variety of recordings which use different formats from MP3 to ones of much higher quality, and he reports that each year the preference for music in MP3 format rises. Berger says that young people seemed to prefer 'sizzle sounds' that MP3s bring to music because it is a sound they are familiar with. 'The music examples included both orchestral, jazz and rock music. When I first did this I was expecting to hear preferences for uncompressed audio and expecting to see MP3 (at 128, 160 and 192 bit rates) well below other methods (including a proprietary wavelet-based approach and AAC),' writes Berger. 'To my surprise, in the rock examples the MP3 at 128 was preferred. I repeated the experiment over 6 years and found the preference for MP3 — particularly in music with high energy (cymbal crashes, brass hits, etc) rising over time.' Dale Dougherty writes that the context of the music changes our perception of the sound, particularly when it's so obviously and immediately shared by others. 'All that sizzle is a cultural artifact and a tie that binds us. It's mostly invisible to us but it is something future generations looking back might find curious because these preferences won't be obvious to them.'"
I guess this has been posted here before, but just in case... I guess the same kind of thing was said when rock 'n' roll arrived (I guess that was the initial rise of reinforced audio and electrical instruments?) - at the end of the day music is just a pleasant euphoric experience, some people like Jean Michelle Jarre, etc. However, the theme of this forum is figuring out high quality reproduction systems - (building poor ones and cheap ones has already been "done")
(edit: The point of this was supposed to be that ears are "unreliable" and also subject to "preference" and this preference can change through time and will also change based on what you listen to)
Young People Prefer "Sizzle Sounds" of MP3 Format
"Jonathan Berger, a professor of music at Stanford, tests his incoming students each year by having them listen to a variety of recordings which use different formats from MP3 to ones of much higher quality, and he reports that each year the preference for music in MP3 format rises. Berger says that young people seemed to prefer 'sizzle sounds' that MP3s bring to music because it is a sound they are familiar with. 'The music examples included both orchestral, jazz and rock music. When I first did this I was expecting to hear preferences for uncompressed audio and expecting to see MP3 (at 128, 160 and 192 bit rates) well below other methods (including a proprietary wavelet-based approach and AAC),' writes Berger. 'To my surprise, in the rock examples the MP3 at 128 was preferred. I repeated the experiment over 6 years and found the preference for MP3 — particularly in music with high energy (cymbal crashes, brass hits, etc) rising over time.' Dale Dougherty writes that the context of the music changes our perception of the sound, particularly when it's so obviously and immediately shared by others. 'All that sizzle is a cultural artifact and a tie that binds us. It's mostly invisible to us but it is something future generations looking back might find curious because these preferences won't be obvious to them.'"
I guess this has been posted here before, but just in case... I guess the same kind of thing was said when rock 'n' roll arrived (I guess that was the initial rise of reinforced audio and electrical instruments?) - at the end of the day music is just a pleasant euphoric experience, some people like Jean Michelle Jarre, etc. However, the theme of this forum is figuring out high quality reproduction systems - (building poor ones and cheap ones has already been "done")
(edit: The point of this was supposed to be that ears are "unreliable" and also subject to "preference" and this preference can change through time and will also change based on what you listen to)
LinuksGuru said:
On the second point I agree, BUT: most designers are aware of the fact that they cannot predict how a device will sound in a real listening test.
On point 1): no I cannot. BUT: this is really how you should not seriously test audio equipment.
My method is that I read a lot about pieces of equipment before I decide to do a listening test. Preferably technical reports and listening tests of persons that have no commercial interest in the product. Then I evaluate the price and the expected increase in performance and may or may not buy something. So usually I buy only one part as a replacement for the old and I have to do only one comparison. Mostly I get the improvement that I expected not because my ears are perfect, but because I have simplified the comparison. Mostly the difference is so clear that there is no need to switch back to the old situation. Sometimes, e.g. with software settings, I go up and down a few times before taking a decision.
This is a relative test, but it is the only sensible way. A particular cable or capacitor or whatever may work very well in my system but could be a disappointment in another setup. That is one of the reasons why your cable test does not work. Another one is that it can take a long time before you can judge a component. This breaking-in effect definitely occurs with cables, speaker units and capacitors and makes it impossible to judge 10 pieces in a good test of a sensible duration.
Being used to a particular sound is certainly a determining factor in comparisons. The MP3 preference brought up by ewildgoose is a good example. But again, that is why my own system is my reference when I plan to change something and the general reference is a good performance with good acoustical instruments.
Kind regards,
Eddie
Hi,
which stereo recording software do we have, that is for stereo input (and pref. only stereo for easy use), reads both from digital and analog inputs (and via pipe for integration with e.g. ecasound), has a dB-scale for analog input, doesn't touch the digital input stream and is small and easy?
Rüdiger
which stereo recording software do we have, that is for stereo input (and pref. only stereo for easy use), reads both from digital and analog inputs (and via pipe for integration with e.g. ecasound), has a dB-scale for analog input, doesn't touch the digital input stream and is small and easy?
Rüdiger
ewildgoose said:
Hello ewildgoose,
Forgot to answer this one up to now. Please have a look at:
http://www.diyaudio.com/wiki/index.php?page=LINUX+Audio+Ecasound
All scripts I use(d) come from Soundcheck. Ecasound uses SOX as a sort of pre-processor. I am not familiar with the details.
Kind regards,
Eddie
Hi folks.
I would like to prepare a Linux-Audio-PC-HW-Config Wiki to gather what has been discussed over here and at other places such as AA.
In earlier posts we discussed some basic characteristics. Perhaps it is a good idea to nail it down more thoroughly . With all your experience, we should manage to configure some real nice toys.
I am thinking of three rather "self-explaining" configurations. (It might be good to switch "Audio" against Multimedia)
1. Linux Audio DSProcessor
2. Linux Audio StreamingClient
3. Linux Audio NetworkServer
What do you think?
Cheers
(Perhaps I better fork into a new thread for not hijacking this thread.)
I would like to prepare a Linux-Audio-PC-HW-Config Wiki to gather what has been discussed over here and at other places such as AA.
In earlier posts we discussed some basic characteristics. Perhaps it is a good idea to nail it down more thoroughly . With all your experience, we should manage to configure some real nice toys.
I am thinking of three rather "self-explaining" configurations. (It might be good to switch "Audio" against Multimedia)
1. Linux Audio DSProcessor
2. Linux Audio StreamingClient
3. Linux Audio NetworkServer
What do you think?
Cheers
(Perhaps I better fork into a new thread for not hijacking this thread.)
EddieV said:
Based on this I am not sure why you previously used Brutefir at all?
Ecasound is just a-n-other sound server. It competes with Jack and Pulseaudio (and a bunch of others) and it has a bunch of nice features and a bunch of limitations.
Brutefir is an audio convolver and used mainly for mangling your audio in a specific way (eg applying some sort of FIR filtering). JConv is another example of such a utility
You seem to be chasing network transparency, and this is problematic for various reasons, hence the small number of audio servers supporting this. If you don't need accurate sync then as you already showed, netcat is fine for this kind of thing. If you need sync and good handling of clocking multiple sources then it all gets a lot more complicated and stuff like netjack2 / pulseaudio seem to be the current leaders
On a related note, this link may be interesting - compares various sample rate convertor's performance.
http://src.infinitewave.ca/
soundcheck said:
You may need to highlight exactly what you are looking at?
Sox certainly has improved a lot in these tests - early days it was pretty poor. However, in the tests above there are a whole bunch of convertors which have very adequate quality to my mind.
libsamplerate (1.1.3 and newer) is operating down at the -120dB level with low enough computation demands to be done in realtime. Sox and several others are well in excess of that and the sox convertor also has a slightly higher bandwidth - however, I'm not sure of the practical benefit of converters giving better than 96dB, and certainly seems of dubious value once you start hitting 120+dB? Sure, no harm if it's offline and computing power is available, but I think it's would be wrong to actually rank converters at that level - they are either acceptable, or below acceptable
However, related question, but why are you resampling at all?
Also you say "offline convolver", but what are you convolving with?
In my setup I run the audio chain at 44Khz and only resample stuff which is outside of that. In my case this means only DVDs and TV. Both of these I am happy to run through "decent" performance resamplers. (my quality requirements are certainly lower for video than pure audio)
Good luck
Ed W
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.