Linux Audio the way to go!?

Status
Not open for further replies.
Jump to Latest
#884
Re: ECASX - The new Linux audio-player sound-quality reference

soundcheck said:

There is no better "upsampling" player on the planet I'd guess. This need to be confirmed
by some volunteers of course. 😉
Click to expand...


Wow! ECASX sounds like an exciting thing.

Alright, enough motivation to (finally) get rid of the USB hassle and switch to a regular digital output. I can hopfully offer a balanced headphone system to your testing pool soon.
 
#889
Re: ECASX - The new Linux audio-player sound-quality reference

soundcheck said:
It sounds IMO a lot better then any standard player you'll find under Linux.
You'll experience something like as if somebody has taken the towel away
from of your speakers. 😉
Click to expand...

Make that a wet towel taken away from speakers. With soundcheck's help I have this running and agree it is much better than any of many Linux players I have used to date.
 
#892
See below . It seems to change some bytes!

sox output:

Code: 
sox rate: has no effect in this configuration
sox sox: effects chain: input      96000Hz 2 channels 24 bits (multi)
sox sox: effects chain: output     96000Hz 2 channels 24 bits (multi)

Files:

Code: 
 124841432 2009-01-16 10:25 02-John_Gorka-The_Gypsy_Life-I_Saw_A_Stranger_With_Your_Hair.wav
 124840424 2009-01-16 10:22 02test.wav
 
#894
You need to run 24/96 hirez material to get it.

I read now in the FAQ4 @ SOX to change -t wav to -t wavpcm which was just half of the story.

what finally worked - was:

sox in2496.wav -t wavpcm out2496.wav vol 0db

I added some comments to the bugtracker over there. Somebody else already filed a bug-report.



BTW: There must be an option to get 64bit float processing up'n running! Did you figure
out how to do this? By default it is 32bit afaik.
 
#895
I did test with 96/24 and received identical results too.

I read now in the FAQ4 @ SOX to change -t wav to -t wavpcm which was just half of the story. what finally worked - was: sox in2496.wav -t wavpcm out2496.wav vol 0db I added some comments to the bugtracker over there. Somebody else already filed a bug-report.
Click to expand...

I see, your input file was the extended wavpcm format, and sox automatically converted to the standard wav. Then there is no problem, it is just a matter of different header, resulting in different size (the standard wav header is shorter).

BTW: There must be an option to get 64bit float processing up'n running! Did you figure out how to do this? By default it is 32bit afaik.
Click to expand...

Just check the source code. SoX is internally using int32 for input/output of the filters. It is up to the filter to use a different resolution internally, e.g. rate.c uses double, i.e. float64 for samples and coefficients.

What kind of float64 processing do you mean? int32 for filter I/O is just fine, each filter I/O in the chain produces just LSB of int32 rounding error which is absolutely OK unless you have hunders of filters in the chain (very unlikely 🙂 ), accummulating the rounding errors up to the LSB of the 24-bit real-world DACs.
 
#896
Hi,
one question:
The DAC chip of my onboard sound system claims to have a 20 Bit PCM Resolution .

shouldn't that mean, if I set the parameters in ecasx to
bit=20
srcrate=48000

that the chip does not resample the pcm stream?

Instead, ecasx aborts playing (after resampling) without an error. With 16 bit and 24 bit setting, it plays
Rüdiger
 
#897
phofman said:
I did test with 96/24 and received identical results too.



I see, your input file was the extended wavpcm format, and sox automatically converted to the standard wav. Then there is no problem, it is just a matter of different header, resulting in different size (the standard wav header is shorter).



Just check the source code. SoX is internally using int32 for input/output of the filters. It is up to the filter to use a different resolution internally, e.g. rate.c uses double, i.e. float64 for samples and coefficients.

What kind of float64 processing do you mean? int32 for filter I/O is just fine, each filter I/O in the chain produces just LSB of int32 rounding error which is absolutely OK unless you have hunders of filters in the chain (very unlikely 🙂 ), accummulating the rounding errors up to the LSB of the 24-bit real-world DACs.
Click to expand...


In brutefir you can clearly hear an improvement from 64over 32bit.

So - you're telling me that "rate" uses 64bit double - that's good to hear. 😀

THX a lot.
 
#898
Hi volunteers.

I just finished ecasx Rev 1.01

# Rev 1.01 : 01/16/2009 :
Introduction of gapless playback ( conversions are done in background now) , non-realtime volume control in "db" attenuation, just two files instead of three kept in RAM in lowrammode , automatic file-format/samplerate/bit-depth recognition, improved documentation, finetuning and cleanup

I'll send it over in a minute. Let me know what you think.

Cheers
Klaus
 
#899
soundcheck said:

In brutefir you can clearly hear an improvement from 64over 32bit.
Click to expand...

I did say it uses int32 for filter input/output. Brutefir is using float64 for the actual filters calculation (just as the rate filter in sox does), but 32/24bit for input/output too (I do not know any ready-to go infrastructure supporting float64 for stream interchange using float64 (jack, alsa plugins, ASIO etc.)).
 
#900
phofman said:


I did say it uses int32 for filter input/output. Brutefir is using float64 for the actual filters calculation (just as the rate filter in sox does), but 32/24bit for input/output too (I do not know any ready-to go infrastructure supporting float64 for stream interchange using float64 (jack, alsa plugins, ASIO etc.)).
Click to expand...


Ok Ok. I think we are in line here. 😉
 
Status
Not open for further replies.
Top Bottom