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

[Fernando Lopez-Lezcano]

On Mon, 2010-05-17 at 12:23 -0700, Niels Mayer wrote:
> 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
> 
> 
>         -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. 

I think that clock is used to measure time only. So that jack can
display the length of xruns, etc, etc. 

> 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.

Yes, midi timing would of course be affected (in the regular alsa midi
sequencer api). I guess jack midi should not be affected as the delivery
of messages is synched to the soundcard clock. 

> 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. 

Yes, that is the case. It _could_ affect the sound but not in a subtle
way, rather with a dropout which would be very audible :-)

In fact when there were first problems with multi processor systems and
the TSC (the timer that is part of the cpu) the end result in jack was
the erroneous reporting of xruns. 

> 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?

Yes, that could also be a reason. 

> 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 :-).

-- Fernando