[PlanetCCRMA] Quality of sound on RHEL 6.0 beta and Fedora 13

[Niels Mayer]

On Mon, May 17, 2010 at 9:49 AM, Fernando Lopez-Lezcano <
nando at ccrma.stanford.edu> wrote:
>
> http://ccrma-mail.stanford.edu/pipermail/planetccrma/2010-March/016513.html
> ...
>
The HPET or other clock sources that are used for timing in the kernel
> are _not_ physically connected (to my knowledge) to the clock source
> that ships the samples through the sound card. That is a separate clock,
> either a crystal in the sound card hardware itself or a clock signal
> derived from the master crystal that drives the cpu clock. It does not
> go through the kernel, it is a hardware feature. The kernel will
> (should?) not affect where and how the hardware (a/d:d/a) gets the clock
> from.


I agree. Thanks for clarifying this (again).

However, note http://linux.die.net/man/1/jackd

<http://linux.die.net/man/1/jackd>
>
> -c, --clocksource ( c(ycle) | h(pet) | s(ystem) )

Select a specific wall clock (Cycle Counter, HPET timer, System timer).


If you're telling jackd to run at a certain sample rate, e.g. 48k, how is it
going to know what 48k actually is? Via the clock.

https://wiki.archlinux.org/index.php/User_talk:Hollunder#timers.2C_hpet.2C_hrtimer
indicates
the main improvement w/ using HPET in jack is better midi timing.

http://www.mail-archive.com/proaudio@lists.tuxfamily.org/msg03199.html also
suggests the soundcard crystal oscillator is ultimately in control of the
sample rate, and mentions the only time-related issue is the buffer running
dry. Which could happen if there's a difference between what the soundcard
thinks as 48k and what the system thinks of as 48k.

So If your clock isn't sampling often enough, or accurate-enough,  couldn't
that affect the sound? Although in jack, i guess you'd see that as a buffer
overrun, and increase your buffers to fix it. Perhaps using a desktop audio
system and a media player, you wouldn't get such indication. But then again
pa and dmix in alsa use large buffers to begin with...

One last idea why a system update might improve the sound. Less resampling?
For example if you formerly accessed through alsa dmix at a 48k rate for
compatibility w/ legacy AC-97; now f13 supports native 44.1 and many other
rates, and you can listen to your music at it's original 44.1K sample rate?
Perhaps an improved pulseaudio-> ALSA configuration that just invokes "plug"
to align the sample to whatever is required by the hardware, but not use
"dmix" to resample?

I hope to be freeing up a machine for f13 in the next months so I guess I'll
find out more about F13's ALSA configuration. I might even leave pulseaudio
running
for a bit just to see how things work for everybody else :-).

Niels
http://nielsmayer.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ccrma-mail.stanford.edu/pipermail/planetccrma/attachments/20100517/64823dcc/attachment.html