btw,
did anyone check out sox' ability to make RIAA correction? Would it be possible to perform a real-time RIAA-correction with sox (easily)?
One could build a linear circuit to give an ADC a good working range. One would avoid all the phase non-linearities of an analog filter arrangement.
Rüidger
did anyone check out sox' ability to make RIAA correction? Would it be possible to perform a real-time RIAA-correction with sox (easily)?
One could build a linear circuit to give an ADC a good working range. One would avoid all the phase non-linearities of an analog filter arrangement.
Rüidger
Onvinyl,
the corrent sox offers the riaa filter, see http://sox.sourceforge.net/sox.html
I have not tested the quality, but I guess it should handle realtime filtering on a modern machine. Just put the filter name at the end of the sox command. You can use sox directly for recording too (check out the AUDIODEV environment variable), it is just not very convenient I guess (no input level monitor etc.).
If using the piped mpd for playback, you can append the filter names at the end of the sox command. With the latest sox you do not need to playback further via ecasound (unless it does some other chained filtering for you, which chained filters of sox would likely provide too), just use alsa output of sox directly. It will lower your CPU usage (no extra process) and latency (no extra pipe).
If the realtime filtering takes much of your CPU and you experience infrequent xruns, try to renice the filtering process to higher/est priority and increase the alsa buffer size so that communication wakeups are minimized. It will raise the overall latency but that does not matter unless you are monitoring or editing.
the corrent sox offers the riaa filter, see http://sox.sourceforge.net/sox.html
I have not tested the quality, but I guess it should handle realtime filtering on a modern machine. Just put the filter name at the end of the sox command. You can use sox directly for recording too (check out the AUDIODEV environment variable), it is just not very convenient I guess (no input level monitor etc.).
If using the piped mpd for playback, you can append the filter names at the end of the sox command. With the latest sox you do not need to playback further via ecasound (unless it does some other chained filtering for you, which chained filters of sox would likely provide too), just use alsa output of sox directly. It will lower your CPU usage (no extra process) and latency (no extra pipe).
If the realtime filtering takes much of your CPU and you experience infrequent xruns, try to renice the filtering process to higher/est priority and increase the alsa buffer size so that communication wakeups are minimized. It will raise the overall latency but that does not matter unless you are monitoring or editing.
Onvinyl said:
1. Playback from RAM
2. Non-realtime conversion - which lowers latency/CPU utilisation to <>1% / power consumption/heat
3. My latest version of ecasx has a built-in search function ( based on find/grep) wich is
better then MPD search and makes IMO really sense on large collections
4. I also made it running over network. just configure 1. ssh properly 2. You mount
your music directory over the network ( to get access to the cover-arts) and 3. you
configure launchers, which are starting ecasx from each of your desktops. (I plan to prepare a network-audio WIKI as soon as the DIY-Audio guys have swapped the forum.)
5. The whole chain works in realtime mode SCHED_FIFO.
Refering to phofmanns comment to drop ecasx:
ecasx is IMO currently the best sounding audio engine under Linux, pretty much tuned to best performance.
You can try if you get along with sox or play. As I said - "The sky is the limit" - with the new function.
Read the man pages of Sox and ecasound carefully and you can keep yourself busy for a month of tweaking.
Cheers
soundcheck said:
Again as I have asked several times in the past - please give some reasons why one bit-perfect playback SW using alsa-lib properly should sound different to another SW. And please do not bring the "it is a generally recognized fact..." argument.
ecasound in your setup above does nothing else than get raw data from stdin and call alsa-lib library. Very likely it even converts the data into its internal format float32. It does not hurt for 24bit signal resolution though since float32 has 24bit mantisa (the integer part) and 8bit exponent, thus keeping the conversion bit-perfect.soundcheck said:
soundcheck said:
No doubt ecasound offers more options than sox. That is why I said "unless it does some other chained filtering for you". In your setup above it does none and I am sure adding ecasound to the chain brings no audible advantage. Just as simple aplay would suffice (and likely provide faster startup and lower memory consumption) should you not require any further data processing.
1. My setup above is supposed to show that the whole thing works in general. It is for obvious reasons kept pretty simple.
2. My intention is not to introduce the entire functionality over here. If people are reporting good results with certain applications ( e.g. the RIAA thing , or e.g. best dithering method,
or. e.g. filtering ) we should list them in the WIKI
3. In the past you asked for clarification regarding sound differences and bit transparency.
I remember that.
Keep asking! You won't get "the" answer.
You might ask the guys over here, who used ecasx , what they think about it.
Perhaps you try ecasound first by yourself.
You might also look at audio-asylum. Search for cplay or cics or cmp. cplay is also
written to get around system related distortions.
It is always the same. The worse your digital chain the more evident in terms of
sound quality are optimizations on the PC. It is always related to
jitter/noise/EMI/RFI/power variations, poor ps/poor V-regulations/poor parts/clocking & timing variations/buffering/ even RAM makes a difference.
I am not ambitioned to dig this down further. I accept it as it is.
My time is rather limited. ( I actually spent much2much on all this stuff.)
And the "source" is just a small part of the chain.
Cheers
2. My intention is not to introduce the entire functionality over here. If people are reporting good results with certain applications ( e.g. the RIAA thing , or e.g. best dithering method,
or. e.g. filtering ) we should list them in the WIKI
3. In the past you asked for clarification regarding sound differences and bit transparency.
I remember that.
Keep asking! You won't get "the" answer.
You might ask the guys over here, who used ecasx , what they think about it.
Perhaps you try ecasound first by yourself.
You might also look at audio-asylum. Search for cplay or cics or cmp. cplay is also
written to get around system related distortions.
It is always the same. The worse your digital chain the more evident in terms of
sound quality are optimizations on the PC. It is always related to
jitter/noise/EMI/RFI/power variations, poor ps/poor V-regulations/poor parts/clocking & timing variations/buffering/ even RAM makes a difference.
I am not ambitioned to dig this down further. I accept it as it is.
My time is rather limited. ( I actually spent much2much on all this stuff.)
And the "source" is just a small part of the chain.
Cheers
soundcheck said:Perhaps you try ecasound first by yourself.
I do not like voodoo and I like knowing how things work internally. For that, I read the source code and try to understand it (not always the case
). If alsa output of ecasound is implemented properly, it will sound exactly the same as sox which seems implemented correctly. Writing simple output to alsa is no rocket science, unless you want the magic Lennart does in pulseaudio.soundcheck said:
How does circumventing the windows black box audio layer including closed drivers and the hit-and-trial method of analysing various ways compare to the open-source transparent function of applications, alsa-lib, individual drivers, and mostly documented hardware? There are no software related distortions in the properly implemented and configured bit-perfect linux chain, no matter what the playback application is.
soundcheck said:
In the bit-perfect digital chain the only "analog" factor is noise on power supply and EMI/RFI, affecting sound card clocks and analog circuits. I have checked, tested, and presented results that any other timing issues are irrelevant, provided enough data gets to the card on time. Even for USB adaptive.
The noise issue is serious, pretty complicated to handle, and I do not believe the above mentioned windows software is a cure. The author does hit and trial too and his results vary. Honestly, I have no absolute cure for this issue either. But I know it is not using ecasound instead of aplay for pure alsa playback from a pipe.
I am slowly realizing a bit-perfect network player featuring a low-power/performance CPU, minimum EMI/RFI, linear PSU for twin crystal-clocked decent 192/24/multichannel stock PCI soundcards with optional external clock input, CPU and PCI boards enclosed in separate shielded containers. I know myself, it will not go all the way to a mass production-ready prototype, but it should suffice as a proof of concept. I already have the router board, PCI slots unsoldered from an old MB, miniPCI library component for the eagle DSP SW, PCI-miniPCI adapter for testing the DIY miniPCI-PCI adapter. Designing and manufacturing the adapter PCBs will take some weeks.
This is your problem. You look up the code on one end. And declare it equal!
So it must sound equal, according to your way of thinking .
Testing ecasound just takes 5 minutes and you can be sure if it is equally sounding.
(At least on your - whatever system)
I pretty much doubt that you can be more efficient by just studying the code with all its
complexity.
Since I am not that deep into coding I need to trust my ears. And I certainly won't try to start measuring anything. Other - much more experienced people with real good measurement gear - failed on proving the obvious.
Anyhow: Interesting project you're working on.
You could also use a Beagleboard with direct I2S out. Makes life much easier
then fiddling around with PCI devices I'd guess. Hookup a Buffalo DAC and you're
set. ( at least on a 2 channel basis)
Cheers
So it must sound equal, according to your way of thinking .
Testing ecasound just takes 5 minutes and you can be sure if it is equally sounding.
(At least on your - whatever system)
I pretty much doubt that you can be more efficient by just studying the code with all its
complexity.
Since I am not that deep into coding I need to trust my ears. And I certainly won't try to start measuring anything. Other - much more experienced people with real good measurement gear - failed on proving the obvious.
Anyhow: Interesting project you're working on.
You could also use a Beagleboard with direct I2S out. Makes life much easier
then fiddling around with PCI devices I'd guess. Hookup a Buffalo DAC and you're
set. ( at least on a 2 channel basis)
Cheers
soundcheck said:This is your problem. You look up the code on one end. And declare it equal!
So it must sound equal, according to your way of thinking .
Testing ecasound just takes 5 minutes and you can be sure if it is equally sounding.
(At least on your - whatever system)
I pretty much doubt that you can be more efficient by just studying the code with all its
complexity.
I can imagine audiophiles fight about analog interconnect cables. I never thought they would fight about algorithms, producing the same data. But if you want to have voodoo, go for it. Just please do not confuse linux newcomers along the way.
soundcheck said:
I like my ears too - they hear what I want to hear
soundcheck said:
On one hand you argue about ecasound producing better sound than aplay or sox even though it outputs the same data, on the other hand you do not mind:
* quality of I2S clock - the beagleboard uses PLL to generate I2S clock from the main clock
* bit-imperfect asynchronous reclocking in Buffalo DAC
* noisy power supply for the I2S source (though I like the fact there is no onboard SMPS)
* inability to separate the timing-nonsensitive data source and timing-sensitive I2S generator into shielded containers. The I2S line to the DAC should be as short as possible since it carries the most sensitive clock of the whole setup.
Plus the maximum sample rate limited to 48kHz does not even allow for CPU/GPU upsampling.
1. This is an audio forum. Even hackers can learn. The biggest problem are narrow
minded people who try to talk down obvious things, because they can not explain these.
And even worse - they are not even willing to try these. This I'd call typical "manufacturer"
behavior. They need to protect their own "story"/"products" . A year later they come
up with the same ideas and selling them as their inventions. ( see audio asylum:
happens all the time)
2. I am going to have as many Linux-Audio beginners to try to squeeze the best sound out
of the PC as possible. It doesn't cost anything.
Did you notice any feedback of the folks who tried my "ecasx" , that the whole thing I am
talking about is Voodoo - just a wishful thinking paranoia.
3. Beagleboard
1. You can feed the board even with a battery supply. Switching supply arguments are
nonsense in this context. Many audio-servers (Naim/Linn, you name it) and
pro soundcards are actually using FGPAs. In the end it'll be the way you connect your
DAC to I2S.
2. Yes the Sabre DAC does upsampling.-- So what! -- Buy yourself a piece, listen, and
then we can continue this discussion.
3. The great thing about the board is that it is very small. You can hook it up right next to
your DAC. I2S Cable length is IMO not an issue.
4. 48khz though is an issue. I wasn't aware of this limitation.
Cheers
minded people who try to talk down obvious things, because they can not explain these.
And even worse - they are not even willing to try these. This I'd call typical "manufacturer"
behavior. They need to protect their own "story"/"products" . A year later they come
up with the same ideas and selling them as their inventions. ( see audio asylum:
happens all the time)
2. I am going to have as many Linux-Audio beginners to try to squeeze the best sound out
of the PC as possible. It doesn't cost anything.
Did you notice any feedback of the folks who tried my "ecasx" , that the whole thing I am
talking about is Voodoo - just a wishful thinking paranoia.
3. Beagleboard
1. You can feed the board even with a battery supply. Switching supply arguments are
nonsense in this context. Many audio-servers (Naim/Linn, you name it) and
pro soundcards are actually using FGPAs. In the end it'll be the way you connect your
DAC to I2S.
2. Yes the Sabre DAC does upsampling.-- So what! -- Buy yourself a piece, listen, and
then we can continue this discussion.
3. The great thing about the board is that it is very small. You can hook it up right next to
your DAC. I2S Cable length is IMO not an issue.
4. 48khz though is an issue. I wasn't aware of this limitation.
Cheers
soundcheck said:
I also added a small section of how to to configure internet radio streams within mpd. This is really a no-brainer. ( Try my example station
Cheers
Klaus, thanks again for your efforts! Radiostreaming doesn't work so far, anyway. I type your commands (inserting my playlists folder) but nothing happens.
Rüdiger
soundcheck said:
You are mixing many things. I said that claiming pure alsa playback via piped ecasound sounds better than pure playback via piped sox/aplay is voodoo, and I stand firmly behind it.
But I have never mentioned your script. Hard drive operation/mouse operation makes a lot of noise on power supply lines, I can hear it on my work PC with T-amp powered by the PC PSU. Playback from RAM, as long as the HDD is idle/spun down, keeps the power cleaner, no doubt about it.
That is the reason I want to avoid using internal PC PSU for the sound card at all. That way all the HDD/mouse/CPU load issues will be circumvented. And I stay behind my statement that if you can ignore the power voltage noise, all you need is bit-perfection and timely delivery. There are many ways to provide these too and they all sound the same (aplay, sox, ecasound, mpd, etc).
The PC power line noise is basically impossible to get rid of properly and completely. I do not want to fight it, I want to ignore it.
Many single board computers feature onboard SMPS for the CPU, just check their pictures on google images.
Plus the way you generate your I2S first, it is
Asynchronous upsampling is an imperfect way to fight jitter. The DAC may sound good (subjectively), but it still uses a technology which produces distortion. By no mean is it better than clean clock without asynchronous upsampling in the first place.
There are other cards of comparable size, such as the inexpensive RouterStation with three miniPCI slots http://ubnt.com/products/rs.php (unfortunately with a SMPS onboard).
The I2S cable length is of MAJOR importance. Try playing with it, you will find out that without any driver (LVDS etc.), the sound starts deteriorating just after 10-20 centimeters. I2S carries the final DAC clock, unlike e.g. USB, PCI, etc., and is very sensitive to longer runs.
Onvinyl said:
Rüdiger.
THX for the feedback.
Have a look again at the Wiki (I missed the .m3u sufffx on the new playlist and the "mpc update" ). It should work now. I just tested it with another station.
Let me know if you get it going.
Note:
I still have problems to get the internet stream out to the pipe output. I need to check what's going on there.
In minion you
1. selected the playlist in the left column
2. you selected the stream in the center column
3. you clicked "add selected"
4. switched to a non-pipe-output
5. you started playback
And it is still not working? Hmmh
Something wrong with the URL? I just had this particular URL playing.
One more: If you right-click in the right "current playlist" column of minion, you can choose "Add URL to playlist" . Enter your URL. Select and play.
Where to get the URLs.: I use streamtuner ( sudo apt-get install streamtuner) and look them up in the properties. ( No idea if there is an easier way)
1. selected the playlist in the left column
2. you selected the stream in the center column
3. you clicked "add selected"
4. switched to a non-pipe-output
5. you started playback
And it is still not working? Hmmh
Something wrong with the URL? I just had this particular URL playing.
One more: If you right-click in the right "current playlist" column of minion, you can choose "Add URL to playlist" . Enter your URL. Select and play.
Where to get the URLs.: I use streamtuner ( sudo apt-get install streamtuner) and look them up in the properties. ( No idea if there is an easier way)
Hi phofman,
mmmh... I'm currently playing with I2S out of the ESI Juli@ internal connector. To date I've done some quick test connecting it directly to my DAC (a NorthStar design model 192) I2S input with a run of cat-5 cable (~50 cm).
Of course that's way less than optimal. Way too long a cable to work without a buffer plus missing level conversion from the 3.3V on the Juli@ to the 5V expected by the DAC input.
It works.
Nonetheless, to get the most out of it obviously I need to build an I2S level shifter + buffer. I wonder: has anybody done a circuit like that before and is willing to share it?
mmmh... I'm currently playing with I2S out of the ESI Juli@ internal connector. To date I've done some quick test connecting it directly to my DAC (a NorthStar design model 192) I2S input with a run of cat-5 cable (~50 cm).
Of course that's way less than optimal. Way too long a cable to work without a buffer plus missing level conversion from the 3.3V on the Juli@ to the 5V expected by the DAC input.
It works.
Nonetheless, to get the most out of it obviously I need to build an I2S level shifter + buffer. I wonder: has anybody done a circuit like that before and is willing to share it?
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.