Linux Audio the way to go!? - Page 103 - diyAudio
Go Back   Home > Forums > Source & Line > PC Based

PC Based Computer music servers, crossovers, and equalization

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 23rd March 2009, 12:27 PM   #1021
diyAudio Member
 
soundcheck's Avatar
 
Join Date: Mar 2005
Location: D
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
  Reply With Quote
Old 23rd March 2009, 12:37 PM   #1022
anli is offline anli  Russian Federation
diyAudio Member
 
Join Date: Oct 2004
I have tried to configure MPD with ecasound, but MPD doesn't understand "pipe" output type.
  Reply With Quote
Old 23rd March 2009, 01:03 PM   #1023
diyAudio Member
 
Join Date: Aug 2008
Quote:
Originally posted by 1audio
LinuksGuru

I'm a little confused. You can get uATX and even miniITX motherboards with onboard HDMI and support for 7.1 audio. They are starting to have enough video horsepower to anything an AV system would want. Perhaps a little more on your goals would help us all work together and share insights. I'll be happy to share my almost current knowledge of media motherboards. I need assistance in packaging a Linux that will be a very focused high performance music player.
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.
  Reply With Quote
Old 23rd March 2009, 01:05 PM   #1024
diyAudio Member
 
soundcheck's Avatar
 
Join Date: Mar 2005
Location: D
Quote:
Originally posted by anli
I have tried to configure MPD with ecasound, but MPD doesn't understand "pipe" output type.

You need to install if from sources (git) to get access to the feature! They introduced the feature two weeks ago.

Lookup my mpd-wiki for details.

Cheers
  Reply With Quote
Old 23rd March 2009, 01:05 PM   #1025
diyAudio Member
 
uli.brueggemann's Avatar
 
Join Date: Nov 2006
Quote:
2. I keep telling that many of ongoing processes "somehow" do affect the sound quality. Differently on different systems. Prove the opposite!
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.
  Reply With Quote
Old 23rd March 2009, 01:11 PM   #1026
diyAudio Member
 
Join Date: Aug 2008
Quote:
Originally posted by soundcheck


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.
  Reply With Quote
Old 23rd March 2009, 01:25 PM   #1027
diyAudio Member
 
soundcheck's Avatar
 
Join Date: Mar 2005
Location: D
Quote:
Originally posted by uli.brueggemann


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.
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
  Reply With Quote
Old 23rd March 2009, 03:12 PM   #1028
phofman is offline phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
Quote:
Originally posted by soundcheck
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.

Quote:
Originally posted by soundcheck
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.
[/B]
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.
  Reply With Quote
Old 23rd March 2009, 04:50 PM   #1029
diyAudio Member
 
soundcheck's Avatar
 
Join Date: Mar 2005
Location: D
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
  Reply With Quote
Old 23rd March 2009, 04:58 PM   #1030
phofman is offline phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
Quote:
Originally posted by soundcheck

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?
I did not read from other readers about noticing the difference between MPD and ecasound either. But I may have overlooked that.
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off



New To Site? Need Help?

All times are GMT. The time now is 10:42 PM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright 1999-2014 diyAudio

Content Relevant URLs by vBSEO 3.3.2