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

[Donald Steven]

Using an Audigy 2.  I don't know how to do an a/b, since I can only boot 
one OS at a time.

Don

On 05/17/2010 12:49 PM, Fernando Lopez-Lezcano wrote:
> On Mon, 2010-05-17 at 08:25 -0700, Niels Mayer wrote:
>    
>> On Mon, May 17, 2010 at 6:55 AM, Donald
>> Steven<t6sn7gt at aim.com>  wrote:
>>          Is it my imagination, or is the basic sound quality of RHEL
>>          6.0 beta and
>>          Fedora 13 improved over previous versions.  To my ears, it has
>>          a clarity
>>          I haven't heard before.
>>      
> Hi Donald, which sound card are you using? Are you doing a/b tests? How?
>
>    
>> A more stable and less jittery clocksource might be the reason for
>> improved clarity. Jittery clocks are the main reason why ditgital
>> sound can be so crappy, and the reason why studios aiming for the
>> highest fidelity usually use external precision wordclocks
>> ( http://www.apogeedigital.com/products/big-ben.php )and
>> jitter-reducing external a/d&d/a's
>> like http://www.apogeedigital.com/products/rosetta-series.php  .
>>
>> Perhaps F13 implements the "audiophile tweaks" I've heard mentioned in
>> chat:
>> http://ccrma-mail.stanford.edu/pipermail/planetccrma/2010-March/016511.html
>>      
> See also:
> http://ccrma-mail.stanford.edu/pipermail/planetccrma/2010-March/016513.html
>
>    
>> Might be a good idea to see how your HPET timers are configured... A
>> stock F12 x86_64 gives:
>>
>>
>>          gnulem-163-~>
>>          cat /sys/devices/system/clocksource/clocksource0/available_clocksource
>>          tsc hpet acpi_pm
>>          gnulem-164-~>
>>          cat /sys/devices/system/clocksource/clocksource0/
>>          available_clocksource  current_clocksource
>>          gnulem-164-~>
>>          cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>>          tsc
>>
>>
>> What are the results for F13?
>>      
> This is IMHO irrelevant.
>
> 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.
>
> So, an improvement in HPET or other timing sources will __not__ affect
> the jitter of the digital audio stream.
>
> If there is a measurable improvement in sound quality, it is more likely
> to come from a change in default settings in the alsa driver mixer,
> perhaps bypass digital processing that was happening in the signal path
> before (for example, a simple change in a _volume_ setting might account
> for better perceived sound, _all_ other things being equal).
>
> -- Fernando
>
>
>