[ALSA - driver 0001225]: RMS hardware input and software plaback levels are incorrectly reported under 64 bit linux

[bugtrack@alsa-project.org]

A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1225> 
======================================================================
Reported By:                ckg
Assigned To:                charbonnel
======================================================================
Project:                    ALSA - driver
Issue ID:                   1225
Category:                   PCI - RME HDSP
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Distribution:               
Kernel Version:             2.6.11
======================================================================
Date Submitted:             07-01-2005 20:11 CEST
Last Modified:              07-03-2005 05:22 CEST
======================================================================
Summary:                    RMS hardware input and software plaback levels are
incorrectly reported under 64 bit linux
Description: 
I'm using the PCI HDSP with a Multiface interface,  Everything appears to
be correct with the audio, but the hdspmixer reports bogus valus for
hardware input and software playback RMS levels.  The peak leavels are
correct.  The problem happens when the driver is compiled into the kernel
and when it is a module.

I think the problem is caused because the rms regesters are positioned at
a 4 byte but not an 8 byte boundary on a 32 bit system, but on a 64 bit
system, they are movd back 4 bytes to an 8 byte alignment
======================================================================

----------------------------------------------------------------------
 charbonnel - 07-02-05 08:42 
----------------------------------------------------------------------
Hi,

It sounds similar to a bug in the byte swapping code that was fixed some
time ago.
(see ALSA BUG https://bugtrack.alsa-project.org/alsa-bug/view.php?id=0000801)
Do you use the in-kernel alsa driver with 2.6.11 ? If so they may be a
little old.
What's the version reported by cat /proc/asound/version ?
I suspect your patch seems to fix the problem but introduces a one channel
offset in the metering values.

Thomas

----------------------------------------------------------------------
 ckg - 07-03-05 05:22 
----------------------------------------------------------------------
Thomas,

This sounds like the same problem. cat /proc/asound/version reports that
I'm running version 1.0.8.  I am using the in-kernal driver.
I took a look at your patch for the problem.  I haven't tried it.  There
seems to be something interesting going on here and I am not able to
completely grasp what is happening.  Here's the situation:
My patch does not appear to introduce a one channel offset.  I have tested
extensively and (unless I am seriously missing something) correct levels
are reported on the correct inputs.
While debuggin my guess was that running 64-bits caused the port space to
be positioned at an 8 byte boundary.  I determined that I needed to jump
backwards four bytes and everything worked great. but... while debugging I
noticed that when I turned the gain up very high on my pre-amp and fed
low-level random noise into channel two the hdspmixer would show the rms
levels changing on channel one.  In fact, as I would turn up the gain on
channel two, the rms level would flucuate up and down repeatedly on
channel one.  My guess was that the least significant bytes of the rms
value on channel one was being read into the most significant bytes of the
rms for channel one.  The trouble is that in order to fix this issue I
would need to offset the port addresses by -12, not -4.
If we assume that your fix is correct then it seems quite logical that my
fix would introduce a one channel offset.  The vise-versa is also true.  I
need to sleep on this and perhaps something bright will occur to me.  In
the mean time, both our fixes seem to work, and I wonder if maybe neither
of them is entirely correct... Hmmm.  Show me what I'm missing.

~ckg

Issue History
Date Modified  Username       Field                    Change              
======================================================================
07-01-05 20:11 ckg            New Issue                                    
07-01-05 20:11 ckg            File Added: hdsp.patch                       
07-01-05 20:11 ckg            Kernel Version            => 2.6.11          
07-02-05 08:42 charbonnel     Note Added: 0005352                          
07-03-05 05:22 ckg            Note Added: 0005369                          
======================================================================




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click