Cics - Cplay and Cmp2

[soundcheck]

Hi there.

I 'd like to refer you to Cics from Audio Asylum if you are still interested in Microsoft XP based audio. Cics has just released a new Wiki related to CMP2 and Cplay.

He went deep down in the jungle of XP and PC HW to squeeze the best sound out of it.

I think he did a great job - just on the wrong operating system.

Cics Wiki

There is some real good stuff over there.

After all the whole story is pretty much in line what I am doing under Linux.

[Greg Stewart]

See thread here on cMP2 mods:

cMP2 DIY Mods...

I've asked the administrator to move it to this forum.

Greg in Mississippi

[phofman]

I am sorry but just a quick look at the wiki shows numerous unsupported arguments regarding the latency http://cplay.sourceforge.net/pmwiki....ay.ASIOLatency

Quoting:
From a Jitter viewpoint, when a soundcard's buffer is populated (whilst the other buffer is converted to SPDIF or whatever), there's a burst of electrical activity. The idea is to keep this burst as short as possible thereby reducing interference to the soundcard's XO, i.e. reduce Jpp. We achieve this by setting latency to the lowest possible level. Of course, using such a low latency would mean more frequent buffer loads. This is the ASIO frequency (or ASIO Hz). At 32 samples latency for 96k output, ASIO Hz is 3kHz. This is now periodic in nature and is digitally induced. We now have Periodic Jitter - the worst kind which exists for all digital playback systems. ASIO gives us control over this.

This is not how PCI cards work. ASIO (or alsa) latency has nothing to do with filling the internal card buffer the author talks about, but with how frequently the card is given a new DMA address and the data buffer length.

ice1724.c:

	val = (8 - substream->runtime->channels) >> 1;
	outb(val, ICEMT1724(ice, BURST));

	outl(substream->runtime->dma_addr, ICEMT1724(ice, PLAYBACK_ADDR));

	size = (snd_pcm_lib_buffer_bytes(substream) >> 2) - 1;
	/* outl(size, ICEMT1724(ice, PLAYBACK_SIZE)); */
	outw(size, ICEMT1724(ice, PLAYBACK_SIZE));
	outb(size >> 16, ICEMT1724(ice, PLAYBACK_SIZE) + 2);
	size = (snd_pcm_lib_period_bytes(substream) >> 2) - 1;
	/* outl(size, ICEMT1724(ice, PLAYBACK_COUNT)); */
	outw(size, ICEMT1724(ice, PLAYBACK_COUNT));
	outb(size >> 16, ICEMT1724(ice, PLAYBACK_COUNT) + 2);

The driver tells Envy24HT the address in RAM where the data ring buffer starts, how long the buffer is (playback_size, corresponding to buffer size in alsa terms) and after how many bytes read from RAM over DMA to generate interrupt (playback_count, corresponding to period size in alsa terms). The interrupt tells the driver/alsa-lib that the current part of the buffer has been read and is available for rewriting with fresh data. Meanwhile, the card continues reading the rest of the ring buffer, i.e. playing the samples stored there, until DMA is stopped when the stream gets stopped by the application.

As everyone can read in Envy24HT datasheet, the chip itself has only an internal buffer of 12 samples x 8 channels x 24bits, i.e. 12 sample rate periods long. The only parameter which can change the frequency of reading from DMA (the argument the author uses for small latency!) is the burst size (register MT19) which is strictly tied to the number of played channels and absolutely unrelated to asio/alsa latency.

In fact, the latency controls length of the buffer and period, i.e. how long the card's DMA controller will be left to do its job of copying data from RAM to that tiny internal buffer without bothering the CPU for new address/buffer length information.

I do not belive that just telling the card where it finds its DMA buffer more than 1000 times a second can have a positive impact on the output jitter. On the contrary I would rather tell the card a few times a second and let it do its job.

That with keeping the periodic jitter above the PLL's cutoff would make sense if the information in the first part of the article was correct.

This just shows how many windows optimizations are based on plain assumptions of how things work. In linux we have the source code and datasheets available and do not have to just assume.

[phofman]

Just a correction - the interrupt from PCI card does not cause the driver tell the card new DMA parameters, just informs the driver that the card has finished reading a particular part of the DMA ring buffer by calling snd_pcm_period_elapsed(). E.g. see method snd_vt1724_interrupt in ice1724.c. It generally means under steady conditions the interrupt leads to no subsequent extra communication with the card.

[soundcheck]

THX phofman for the explanation.

There are actually more subjects you could question.

His problem is that he tries to explain everything what causes this or that change
to the sound.

I guess my strategy is a bit more clever: "Try it and make up your own mind!"

[soundcheck]

Originally Posted by Greg Stewart

See thread here on cMP2 mods:

cMP2 DIY Mods...

I've asked the administrator to move it to this forum.

Greg in Mississippi

THX for pointing it out.

There are quite some other threads in the digital section which could be moved over here.

[phofman]

Originally Posted by soundcheck

His problem is that he tries to explain everything what causes this or that change to the sound.

I have no problem with that approach, in fact it is my preferred mode of operation. But the explanation should not be an artificially made-up argument fitting one's opinion, but a plausible and technically correct analysis.

This takes me back to my explanation of the PCI DMA communication above which is not technically correct and I feel ashamed.

When an application starts playback, it opens the device. Upon opening, the card is told parameters of the DMA ring buffer in RAM (starting address and buffer length) and the how many bytes to read before it generates an interrupt (period size). The driver fills the ring buffer with more than the period size of initial audio data. After that the card is told to start the DMA transfer - the actual playback.

When the card reaches the end of period size, it notifies the driver so that the driver knows current status of the playback. Meanwhile the card continues to read the data from the buffer. When it reaches the end of the buffer (it knows its length), it starts from the begining automatically.

The driver has to make sure the fresh data reach RAM always ahead of the card reading pointer. Therefore the buffer is almost always at least twice the period size - when the card reads one period segment, the driver has time to refresh data in the other period segment.

Now low latency means the buffer is very small, the driver is very little ahead of the card and the card keeps informing the driver very often. A very short delay in filling the buffer causes the card to consume all the fresh data, resulting in audible xruns. That is why the playback chain needs to run with real-time priority on RT kernels.

How such setup could improve the sound sonically is beyond my understanding (and belief).

The author of pulseaudio wrote a very illuminating description of his glitch-free technology http://0pointer.de/blog/projects/pulse-glitch-free.html . Please note the overall HW latencies he would like to reach - several seconds. And that is for good reasons - low CPU load, low consumption, few IRQs. Of course the actual latencies could be much smaller as the pulseaudio server would "inject" low-latency streams (games, midi, audio monitoring/editing) into the ring buffer just ahead of the sound card reading pointer.

This makes sense to me, not the low-latency push for quality audio.

[soundcheck]

Originally Posted by phofman

This makes sense to me, not the low-latency push for quality audio.

What in the end makes sense is the solution which delivers best sound at a certain
point in time. This is my rt-kernel&ecasound&ramdisk buffering for now. ( More and more people are confirming this)

If one day in the far future pulseaudio will manage to beat my rtkernel-/ecasound setup I'll be happy to try it (once in a while I did try it) -- until than I remove it (which is quite a difficult task if you run Ubuntu).

If you read what he is saying you'll realize that the guy is tied to "make it work on all platforms" -- that's bad - sounds like compromises.

Number two: He is listing several problems which do exist. He is complaining about everything and the limitations of Alsa. I say: So what - Instead of writing such an animal as pulseaudio he could have supported Alsa or Jack to get things better.


If you would have listenened to ecasound on a real-time kernel you'd know what I am talking about.


Anyhow thx for the link. I've been there before.

[soundcheck]

Some more:
He is talking about timer limitations of 100Hz! Come on. I was running 10khz two years ago.
The rest of the audio world is running at 1000Hz for quite some time.

>> The glitch-free logic will only be enabled on mmap()-capable ALSA devices and where hrtimers are available.

Perhaps he should talk to the HW manufacturers - the few ones that are supporting Linux - first.

Last: I am really wondering how accurate a SW timer can be.

The only acceptable way would probably be to sync the chain to an external precision clock.

[phofman]

Originally Posted by soundcheck

What in the end makes sense is the solution which delivers best sound at a certain
point in time. This is my rt-kernel&ecasound&ramdisk buffering for now. ( More and more people are confirming this)

Any links? People comparing sound of non-rt kernel to rt-kernel? People comparing bit-perfect playback of ecasound to e.g. bit-perfect MPD? The ram disk makes sense, HDD does produce a lot of noise.

Originally Posted by soundcheck

If one day in the far future pulseaudio will manage to beat my rtkernel-/ecasound setup I'll be happy to try it (once in a while I did try it) -- until than I remove it (which is quite a difficult task if you run Ubuntu).

Any pure alsa-based setup surpasses current pulseaudio, at least the one packaged in ubuntu. I always remove pulseaudio since the technology is not ready for production yet, in my POV. It has a pretty high goal which takes a lot of effort to reach, on all audio layers.

Originally Posted by soundcheck

If you read what he is saying you'll realize that the guy is tied to "make it work on all platforms" -- that's bad - sounds like compromises.

Unless you present arguments, it is a pure speculation. The sound HW is the same on all platforms, the low-level principles too (these follow the common HW functionality).

Originally Posted by soundcheck

Number two: He is listing several problems which do exist. He is complaining about everything and the limitations of Alsa. I say: So what - Instead of writing such an animal as pulseaudio he could have supported Alsa or Jack to get things better.

I belive alsa should stay a lean abstract interface to various sound cards. Most of its user-space stuff has not been very successful. dmix - supports only raw PCI/USB cards, no bluetooth, long latency. The current dmix supports 16-bit resampling only - check the source code. Alsa API is VERY complicated since it has been extended many times and has to be kept backward-compatible. Sure, fixing alsa is doable, but in my eyes that is one of the goals of pulseaudio.

Jack is a professional tool for a limited group of people. The single common sampling frequency does not make it suitable for a broader range of applications. I would not be surprised if pulseaudio gradually employed the jack core principle - applications of the same sample rate communicating via a shared memory, that is latency-free. Sure you could add resampling to jack - and slowly make it a beast similar to pulseaudio.

Originally Posted by soundcheck

If you would have listenened to ecasound on a real-time kernel you'd know what I am talking about.

RT kernel has stability problems on my home machine as well as home testing notebook. It is not a well-tested technology, numerous drivers have problems and cause lock-ups. E.g. some people still report crashes of ice1724 midi on RT ubuntu studio, search the alsa-devel mailinglist. So far nobody has been able to fix it. I used to experience the same problem with ice1724 midi, some hacks of trial/error nature helped, apparently not for everyone.

Properly implemented bit-perfect alsa outputs (ecasound, MPD, sox) sound all the same. Saying one app sounds better in a consistent manner (i.e. on machines with different MBs, PSUs, CPUs, etc.) is voodoo to me.

Unlike mplayer which is very stubborn with resampling/reformatting the audio data based on the actual sound card parameters instead of the parameters supplied by the upper-layer alsa plugins. But it makes it bit-imperfect and it does not conform the initial condition of bit-perfection.

Originally Posted by soundcheck

He is talking about timer limitations of 100Hz! Come on. I was running 10khz two years ago. The rest of the audio world is running at 1000Hz for quite some time.

For pure playback 100Hz with long-enough latency is sufficient. It is your own decision to strain your machine with 10kHz. The audio world you are talking is crucially dependent on low latency for the real-time audio work. Do you think they would find it acceptable to push the play button, wait for a few seconds until the data buffers from HDD to RAM, and then try to make up for the lost seconds with single-millisecond latency setup?

Originally Posted by soundcheck

>> The glitch-free logic will only be enabled on mmap()-capable ALSA devices and where hrtimers are available.

Perhaps he should talk to the HW manufacturers - the few ones that are supporting Linux - first.

Last: I am really wondering how accurate a SW timer can be.

The only acceptable way would probably be to sync the chain to an external precision clock.

Well, are you sure you understand what Lennart is talking about in his article? The hrtimers have nothing to do with audio clock. Since the card is setup to high latency, it reveals its position only few times a second and hrtimers have to "simulate" the card reading pointer so that the upstream knows to which position of the mmapped buffer the low/middle/high latency data should be copied to be properly ahead of the HW reading pointer.

It is pretty difficult to write to a specific part of the buffer by the user-space application if the buffer is not mmapped.

I suggest we stop this discussion since apparently we both are talking about different things.