1. I do trust my ears. How about yours? 
2. I keep telling that many of ongoing processes "somehow" do affect the sound quality.
Differently on different systems. Prove the opposite!
3. You might call it "buffered realtime-stream".
Anyhow - there is no real realtime that's correct. Even a 2707 has a small buffer.
The term is rather used to point out a continuous data stream.
Even a realtime kernel is not realtime. And a process priority under Windows XP
is also called realtime (no comment about that!?!?).
4. I am running non-realtime DSP with my own ecasx player.
ecasound/brutefir is the only process running during playback. MPD is just giving me
( and others) a convenient interface and network capabilities. And comparing MPD with
the MPD/ECASOUND combo speaks for
itself.
Perhaps one day you to try some of my "snakeoil" stuff and then you'll let us know about the reasons for the differences you' ll experience. I am looking forward to it.
Cheers
2. I keep telling that many of ongoing processes "somehow" do affect the sound quality.
Differently on different systems. Prove the opposite!
3. You might call it "buffered realtime-stream".
Anyhow - there is no real realtime that's correct. Even a 2707 has a small buffer.
The term is rather used to point out a continuous data stream.
Even a realtime kernel is not realtime. And a process priority under Windows XP
is also called realtime (no comment about that!?!?).
4. I am running non-realtime DSP with my own ecasx player.
ecasound/brutefir is the only process running during playback. MPD is just giving me
( and others) a convenient interface and network capabilities. And comparing MPD with
the MPD/ECASOUND combo speaks for
itself.
Perhaps one day you to try some of my "snakeoil" stuff and then you'll let us know about the reasons for the differences you' ll experience. I am looking forward to it.
Cheers
1audio said:
I am living in Europe, so choice of hardware is much smaller compared to USA. Additionally, our prices are 40%+ higher. So far we have no uATX m/b with HDMI in nearby sources.
What do you mean high-performance? Ability to play all type of media files? All convert them in batch very fast? Is it stand-alone PC, setup box (aka Apple TV) or embedded? You need to be VERY precise in technical terms.
I don't want to prove the opposite but just to add my thoughts:
If I understand correctly then a soundcard should have two buffers, one buffer to read data from and one buffer to write data into. When a buffer has been read then a buffer switch should take place to access the data from the next buffer. In such a case the soundcard is fully independant of the timing how data are written into the buffer (as long as the adress and data lines to the buffer are properly decoupled). And the soundcard has full control over the timing for the sound data sent to the output, either by an internal clock, by sync'ing to an input or by an external wordclock. Of course we don't need to discuss the clock quality. It has simply to be the best.
Such a design allows to use a PC without or with realtime reaction. The only requirement is that the buffers don't get an overflow or underflow.
The sound is thus fully decoupled from the PC activity.
But if we still notice a sound difference then we need to think about what is going on on the electrical connections. We may get influences by the power supply (e.g. a heavy CPU load may influence the voltage and the soundcard clock starts jittering). We also may get noise introduced by the ground connection (a PC can radiate a lot of noise) or we may get interferences on other common used bus connections.
Anyway I would always prefer to have a soundcard with its own clock. No doubt, if the PC would be responsible for the timing this would be a mess.
My own conclusion: if a soundcard or a DAC shows a different behaviour with different type of oerating systems or with different programs then the design of the soundcard or of the DAC is not ok (similarly a CD player design is not ok when the sound changes with CD fluid treatment). It may help to tweak the PC but IMHO it is better to change the soundcard.
soundcheck said:
Hi there.
I am looking for a small board that covers at least:
1. 4GB RAM
2. PCI-e slot (for soundcard)
3. Fanless
4. Preferably 12V supply
5. Gbit-LAN
6. DVI-D/HDMI (1920*1200)
7. PS/2 ( To avoid USB keyboard and usb-mouse)
The new Nvidia ION seems to be a nice platform. It comes with CUDA capability, which can be used for DSP activity. Perhaps the HDMI IF can be used for multichannel PCM.
However above feature list is not really covered by ION
Any recommendations?
Cheers
Sounds nice but how about Lunux drivers ??? People often wrongly assume if there is a hardware there are fully working drivers for Linux. Yes, nVidia have Linux drivers which are closed-source and known to have regular problems. So far I prefer Intel, at least I can be (almost) sure it will work. Yesterday I have updated my system and GUI have gone with message "Cannot open or move log file /var/log/x.org.log.xxx".
nVidia drivers are pain in the ***, but I have no other choice for video card, ATI card have even worse support for Linux.
uli.brueggemann said:
Hi Uli.
I am exactly saying this all the time. On different chains there'll be different results.
My message:
Give it a try ! If it doesn't improve - great! - your soundcard is probably doing a great job
(or your system is just not able to reproduce these improvements - I have a much harder
time to hear any differences on my desktop system ( EMU0404USB /Adam A5) compared to my main system)
Cheers
soundcheck said:1. I do trust my ears. How about yours?
My ears have been proven unreliable many times. As I said, they hear what I want them to hear. I wonder if it is any different with you.
soundcheck said:
See, here is the point I am trying to explain the whole time. It is NOT about buffering/real-time/continuous data stream. It is only about slaving the WHOLE chain to the clock in the sound card. Every card (even USB adaptive) is controlled by HW clock independent of SW and this clock defines the card jitter (plus the power supply impact). The whole chain in linux is slaved to the card if you use players without reclocking (unlike e.g. pulseaudio outputing to two cards with independent clock).
I know you do not care about technical details, but others may think about this (slightly simplified):
* The master - Crystal clock in the card - controls reading samples from buffer in PCI controller
* The PCI controller reads data from memory via DMA (already PCI clock) to keep the buffer reasonably full. This independent phase can last from few 100s of microseconds up to over 2 seconds without interruption - depends on the PCI controller and buffer size setup.
* When all DMA data are read, the controller throws an interrupt so that Interrupt Service Routine (ISR) can tell the card a new address of newly prepared data in memory.
* When the ISR finishes, the driver knows it must prepare new data and wakes up the application producer thread. The thread reads fast the prepared data and copies it via alsa-lib calls to memory for the DMA. If enough data are copied, the alsa-lib call blocks and the thread is put to sleep.
* Lets say brutefir is piped to the playback application. Once the playback thread reads data from the pipe, brutefir unblocks (wakes up), reads samples from its input, processes them and keeps sending via the pipe until the playback application stops consuming and the pipe gets full, blocking thus brutefir.
* And the same holds e.g. for MPD piping to brutefir - the blocking/waking up due to reading/writing from the pipes (controlled by kernel) propagates pace of the master clock in the soundcard upward through the playback chain. Instead of pipes you can have network sockets - it works the same.
If any part of the chain fails to act on time, an xrun occurs. It produces an audible click which cannot be mistaken for "bit imperfection" or any "nonlinear" sound distortion.
Many playback applications have separate threads for user interface and writing data to alsa-lib so that user is shielded from the synchronous nature of the playback and so that the UI does not interrupt the writer while the driver awaits data.
Now how does real time fit into the picture? To achieve overall low latency, the DMA buffer must be very small so that the card is only slightly ahead of the chain input. That means the card throws interrupts frequently, and the whole chain must respond swiftly. But unblocking a process/thread does not automatically mean it will run right away, it is up to the OS scheduler to decide. And setting the playback application real-time means it is more likely the scheduler will give CPU time to the application and the whole chain will run uninterrupted.
As you can see, the real-time setup has absolutely no impact on the resultant sound clarity, it does not change the data in any way. If the chain cannot keep-up, you hear xruns.
If there is no need for low latency, raising buffer sizes will relieve a lot of strain the chain puts on the system, letting CPU idle more often, lowering power consumption. What is more likely to produce noise on power supply lines - busy CPU waking up processes every miliseconds due to low-latency setup, or sleepy CPU idling tens of ms due to the sound card PCI controller reading samples from memory independently and asking the CPU for action only few times a second?
Let's have readers make their own opinion which concept is more plausible.
Hi phofman.
I do not say you're wrong with your theories. You are the software specialist around here. I am working on a kind of "admin" level.
I do understand what you're saying and referring to. And the readers should listen about what you're saying.
However, reading all your explanations I do miss one point:
You're just not explaining the origin of the sound differences! That's the whole story.
If you're saying - you tried ecasound and compared it to mpd and you couldn't hear any difference, we have a common base to start a discussion. Do you get my point?
Cheers
I do not say you're wrong with your theories. You are the software specialist around here. I am working on a kind of "admin" level.
I do understand what you're saying and referring to. And the readers should listen about what you're saying.
However, reading all your explanations I do miss one point:
You're just not explaining the origin of the sound differences! That's the whole story.
If you're saying - you tried ecasound and compared it to mpd and you couldn't hear any difference, we have a common base to start a discussion. Do you get my point?
Cheers
LinuksGuru said:
The uATX options would be met with this:
M2N68-VM and even though the Nvidia drivers for Linux are marginal they do work. An earlier version of this was used for the LinuxMCE media player platform.
However my interest now is a much lighter weight platform (no fans or other moving parts) for audio only. For AV I would use the Popcorn Hour since it does everything and is an almost open Linux Platform.
there are multiple asynchronous (buffered) steps between data in memory and serial audio data out, eg device memory via dma, shift register parallel->serial and so on. Unless your system is so slow that it just can't keep up with a 44.1 or 192khz data out, causing buffer under-runs, then jitter etc here is not an issue, IMHO.
Also, I would think having a cpu frequently go into sleep mode, and then wake up, which radically changes it's power consumption, and clock speed, would generate quite a bit of (RF, psu) noise.
Also, I would think having a cpu frequently go into sleep mode, and then wake up, which radically changes it's power consumption, and clock speed, would generate quite a bit of (RF, psu) noise.
Hi there.
FYI:
I just learned that after 1.5 years of neglecting a focused maintenance ( was more a sporadic look into it thing) of the realtime kernel patch Th.Gleixner and Ingo Molnar ( the kernel scheduler gurus) sat down to port the linux-rt patch properly to 2.6.29.
http://lkml.org/lkml/2009/3/25/480
Let see. I am just trying to get the 2.6.29-rt1 kernel compiled.
That'll mean of course that even Ubuntu Jaunty (2.6.28) won't show up with this kernel.
Cheers
FYI:
I just learned that after 1.5 years of neglecting a focused maintenance ( was more a sporadic look into it thing) of the realtime kernel patch Th.Gleixner and Ingo Molnar ( the kernel scheduler gurus) sat down to port the linux-rt patch properly to 2.6.29.
http://lkml.org/lkml/2009/3/25/480
Let see. I am just trying to get the 2.6.29-rt1 kernel compiled.
That'll mean of course that even Ubuntu Jaunty (2.6.28) won't show up with this kernel.
Cheers
Converting Ape on Linux (with GUI tool)
Hi,
You can find how to convert APE files on Linux on my web page dedicated to Linux tips and tricks. In short - use K3B.
http://www.starlett.com/~web5_macguru/linux_tips_and_tricks.html
If you have any other question(s) regarding Linux - please let me know.
Hi,
You can find how to convert APE files on Linux on my web page dedicated to Linux tips and tricks. In short - use K3B.
http://www.starlett.com/~web5_macguru/linux_tips_and_tricks.html
If you have any other question(s) regarding Linux - please let me know.
soundcheck said:
I do find these conspiracy theories and suggestions that the PC might be altering your sound behind your back to be quite dull
It should not be too hard to use the digital output on your card and to literally record the output from your two ways of playing back your audio. I would *expect* you to find that the two digital streams are identical (you may need to trim and offset them if you don't have a bit perfect record/playback synchronisation method)
If you don't find this then you need to analyse the PC software side until you find out why the digital data is getting altered.
If you find that the digital data is *identical* (which I would expect) then your problem boils down to good old fashioned "my DAC is cr*p" - and for some reason your DAC is behaving differently when fed the same bitstream in. Plenty of good reasons why this might be so, but the point is that it's not a "PC issue", it's a "I need a more robust DAC" issue
Good luck
Ed W
P.S I have used a Jack + Brutefir setup very successfully for nearly 5 years now. Resampling (only for 48Khz tv output) is done using libsamplerate, which in it's latest iteration appears to be very near top of the tree in resampling performance. The jack chain always runs at 44Khz, so no resampling done for typical CD playback. Output is via RME9632 to a passive pre-amp, then on to some Hypex amps. Read more at http://www.duffroomcorrection.com
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.