RE: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!

RE: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!

[Ivica Ico Bukvic]

Hi all! Great news! I managed to fix the issue in Linux. As I suspected it
was the same problem like in Windows after suspend as the distortion was
similar.

Many thanks to all for all your help! Without you I would be still stuck on
this one tearing my hair out :-).



Conclusion:
===========
Hdsp after adjusting the controller settings works absolutely flawlessly.
Yay!

-----------------------------------------------------

Things that are require attention in order for this fix to work (ENE CB1410
cardbus controller):

1) CRITICAL: Yenta_socket driver needs to be mended to adjust the proper
registers for the ENE CB1410 cardbus as follows*:

a) register 0xc9 on mine was 0x06 (like in Windows after resume) and should
be 0x04 (like in Windows before resume)
b) register 0x81 was 0x90 (again like Windows after resume) and after
connecting the cardbus it was 0xb0, yet in both cases should be 0xd0** (like
in Windows before resume)

*NOTE: It is possible that this kind of behavior might be in part due to the
buggy BIOS of this notebook. Arima is currently working with me in trying to
resolve this possibly utilizing updated BIOS. Nonetheless, IMHO it would be
nice to have this added to the yenta_socket as Arima's successfulness at
fixing it is yet to be ascertained and this one truly seems like a
low-impact fix for the driver.

**I've noted that when I use:

setpci -s a.0 0x81.b

after changing the value to 0xd0 (with setpci -s a.0 0x81.b=d0) it would
tell me that it was equal to f0, yet the "hexdump -v /proc/bus/pci/00/0a.0"
would tell me it was d0 after all (see the log below).

----------

2) PREFERRED: hdsp driver needs to adjust the cardbus controller latency
upon connection and/or resume from standby to ff (even though it will likely
play on the lower latencies as well, this way it will be less likely to
produce xruns and since official RME's driver for Windows does this, Linux
IMHO likely ought to keep-up with their driver and offer same
functionality/behavior for easier troubleshooting).

The register in question is 0x0d (mine was by default in Windows at 0x20
before connection and at 0xff after connection, while in Linux it was at
0xa8 both before and after connecting the cardbus which suggests that the
driver did not properly ramp-up its value to 0xff).

3) FOR FURTHER INVESTIGATION: Does linux hdsp driver force the f0 value upon
the 0x81 register or is it that in Linux one simply cannot select d0 value
for whatever reason (specifying it would revert the value to f0, yet that
did not directly affect the sound and judging from the suggestions of others
that this is a switch for enabling memory burst read stuff perhaps it only
takes two values and each of them possibly populate a range in which case it
should be ok either way). I need to check this a bit more just to see if the
f0 really does mess it up or not.

-----------------------------------------------------

Here's the relevant log of the activity (I am way to tired to convert the
following into a meaningful prose so I am including the console log with
some annotations in parentheses):


<BEGIN>
[root@localhost 00]# hexdump 
-v /proc/bus/pci/00/0a.0 
0000000 1524 1410 0007 0210 0000 0607 a808 0002 
0000010 f000 ffe7 00a0 0200 0200 b005 e000 ffe7 
0000020 e000 ffe7 0000 2000 f000 203f 5000 0000 
0000030 50fc 0000 5400 0000 54fc 0000 010b 05c0 
0000040 161f 2032 0001 0000 0000 0000 0000 0000 
0000050 0000 0000 0000 0000 0000 0000 0000 0000 
0000060 0000 0000 0000 0000 0000 0000 0000 0000 
0000070 0000 0000 0000 0000 0000 0000 0000 0000 
0000080 9021 4044 0000 0000 0000 0000 1002 0100 
0000090 82c0 6044 0000 0000 0000 0000 0000 0000 
00000a0 0001 fe01 0000 00c0 0000 0000 001f 0000 
00000b0 0000 0000 0000 0000 0000 0000 0000 0000 
00000c0 1000 0000 0080 0080 0600 1008 0000 0000 
00000d0 0000 0000 0000 0000 0000 0000 0000 0000 
00000e0 0000 0000 0000 0000 0000 0000 0000 0000 
00000f0 0000 0000 0000 0000 0000 0000 0000 0000 
0000100 

(compare this with a screenshot in Windows -- please note that the value
pairs are reversed for whatever reason (endianness?); the Win32 screenshot
can be found here:
http://meowing.ccm.uc.edu/~ico/eMachines/SE-before_suspend.jpg ; please note
that the numbers are almost identical)

[root@localhost Documents]# setpci -s a.0 0xc9.b 
06 

(this ought to be 04)

[root@localhost Documents]# setpci -s a.0 0x81.b 
90 

(this ought to be d0)

[root@localhost Documents]# hdsploader 
hdsploader - firmware loader for RME Hammerfall 
DSP cards 
Looking for HDSP + Multiface or Digiface cards : 
Card 0 : VIA 8235 at 0x1000, irq 10 
Card 1 : RME Hammerfall DSP at 0x20000000, irq 
11 
Upload firmware for card hw:1 
Firmware uploaded for card hw:1 
[root@localhost Documents]# hexdump 
-v /proc/bus/pci/00/0a.0 
0000000 1524 1410 0007 0210 0000 0607 a808 0002 
0000010 f000 ffe7 00a0 0200 0200 b005 e000 ffe7 
0000020 e000 ffe7 0000 2000 f000 203f 5000 0000 
0000030 50fc 0000 5400 0000 54fc 0000 010b 0500 
0000040 161f 2032 0001 0000 0000 0000 0000 0000 
0000050 0000 0000 0000 0000 0000 0000 0000 0000 
0000060 0000 0000 0000 0000 0000 0000 0000 0000 
0000070 0000 0000 0000 0000 0000 0000 0000 0000 
0000080 b021 4044 0000 0000 0000 0000 1002 0100 
0000090 82c0 6044 0000 0000 0000 0000 0000 0000 
00000a0 0001 fe01 0000 00c0 0801 0000 001f 0000 
00000b0 0000 0000 0000 0000 0000 0000 0000 0000 
00000c0 1000 0000 0080 0080 0600 1008 0000 0000 
00000d0 0000 0000 0000 0000 0000 0000 0000 0000 
00000e0 0000 0000 0000 0000 0000 0000 0000 0000 
00000f0 0000 0000 0000 0000 0000 0000 0000 0000 
0000100 

(hmmm, register 0x81 just became 0xb0 after reconnect but both values are
wrong)

[root@localhost Documents]# setpci -s a.0 
0xc9.b=04 

(ok, here goes nothing :-)

[root@localhost Documents]# setpci -s a.0 0xc9.b 
04 

(so far so good)

[root@localhost Documents]# setpci -s a.0 
0x81.b=D0 
 
[root@localhost Documents]# setpci -s a.0 0x81.b 
f0 

(oops? Let's try that again:)

[root@localhost Documents]# setpci -s a.0 
0x81.b=D0 
 
[root@localhost Documents]# setpci -s a.0 0x81.b 
f0 

(hmmm, let's see the hexdump)

[root@localhost Documents]# hexdump 
-v /proc/bus/pci/00/0a.0 
0000000 1524 1410 0007 0210 0000 0607 a808 0002 
0000010 f000 ffe7 00a0 0200 0200 b005 e000 ffe7 
0000020 e000 ffe7 0000 2000 f000 203f 5000 0000 
0000030 50fc 0000 5400 0000 54fc 0000 010b 0500 
0000040 161f 2032 0001 0000 0000 0000 0000 0000 
0000050 0000 0000 0000 0000 0000 0000 0000 0000 
0000060 0000 0000 0000 0000 0000 0000 0000 0000 
0000070 0000 0000 0000 0000 0000 0000 0000 0000 
0000080 d021 4044 0000 0000 0000 0000 1002 0100 
0000090 82c0 6044 0000 0000 0000 0000 0000 0000 
00000a0 0001 fe01 0000 00c0 0801 0000 001f 0000 
00000b0 0000 0000 0000 0000 0000 0000 0000 0000 
00000c0 1000 0000 0080 0080 0400 1008 0000 0000 
00000d0 0000 0000 0000 0000 0000 0000 0000 0000 
00000e0 0000 0000 0000 0000 0000 0000 0000 0000 
00000f0 0000 0000 0000 0000 0000 0000 0000 0000 
0000100 

(well it says here it is 0xd0 so I guess I'll take hexdump's word for it)

[root@localhost Documents]# hdspconf 
 
HDSPConf 1.4 - Copyright (C) 2003 Thomas 
Charbonnel <thomas@undata.org> 
This program comes WITH ABSOLUTELY NO WARRANTY 
HDSPConf is free software, see the file copying 
for details 
 
Looking for HDSP cards : 
Card 0 : VIA 8235 at 0x1000, irq 10 
Card 1 : RME Hammerfall DSP + Multiface at 
0x20000000, irq 11 
Multiface found ! 
1 Hammerfall DSP card found. 

[root@localhost Documents]# hexdump 
-v /proc/bus/pci/00/0a.0 
0000000 1524 1410 0007 0210 0000 0607 a808 0002 
0000010 f000 ffe7 00a0 0200 0200 b005 e000 ffe7 
0000020 e000 ffe7 0000 2000 f000 203f 5000 0000 
0000030 50fc 0000 5400 0000 54fc 0000 010b 0500 
0000040 161f 2032 0001 0000 0000 0000 0000 0000 
0000050 0000 0000 0000 0000 0000 0000 0000 0000 
0000060 0000 0000 0000 0000 0000 0000 0000 0000 
0000070 0000 0000 0000 0000 0000 0000 0000 0000 
0000080 f021 4044 0000 0000 0000 0000 1002 0100 
0000090 82c0 6044 0000 0000 0000 0000 0000 0000 
00000a0 0001 fe01 0000 00c0 0801 0000 001f 0000 
00000b0 0000 0000 0000 0000 0000 0000 0000 0000 
00000c0 1000 0000 0080 0080 0400 1008 0000 0000 
00000d0 0000 0000 0000 0000 0000 0000 0000 0000 
00000e0 0000 0000 0000 0000 0000 0000 0000 0000 
00000f0 0000 0000 0000 0000 0000 0000 0000 0000 
0000100 

(dang it! 0xf0 even in hexdump now, let's try it again:)

[root@localhost Documents]# setpci -s a.0 
0x81.b=d0 
 
[root@localhost Documents]# setpci -s a.0 0x81.b 
f0 

(DOH!)

[root@localhost Documents]# hexdump 
-v /proc/bus/pci/00/0a.0 
0000000 1524 1410 0007 0210 0000 0607 a808 0002 
0000010 f000 ffe7 00a0 0200 0200 b005 e000 ffe7 
0000020 e000 ffe7 0000 2000 f000 203f 5000 0000 
0000030 50fc 0000 5400 0000 54fc 0000 010b 0500 
0000040 161f 2032 0001 0000 0000 0000 0000 0000 
0000050 0000 0000 0000 0000 0000 0000 0000 0000 
0000060 0000 0000 0000 0000 0000 0000 0000 0000 
0000070 0000 0000 0000 0000 0000 0000 0000 0000 
0000080 d021 4044 0000 0000 0000 0000 1002 0100 
0000090 82c0 6044 0000 0000 0000 0000 0000 0000 
00000a0 0001 fe01 0000 00c0 0801 0000 001f 0000 
00000b0 0000 0000 0000 0000 0000 0000 0000 0000 
00000c0 1000 0000 0080 0080 0400 1008 0000 0000 
00000d0 0000 0000 0000 0000 0000 0000 0000 0000 
00000e0 0000 0000 0000 0000 0000 0000 0000 0000 
00000f0 0000 0000 0000 0000 0000 0000 0000 0000 
0000100 

(at least hexdump is happy)

[root@localhost Documents]# hdspmixer 
 
HDSPMixer 1.6 - Copyright (C) 2003 Thomas 
Charbonnel <thomas@undata.org> 
This program comes with ABSOLUTELY NO WARRANTY 
HDSPMixer is free software, see the file COPYING 
for details 
 
Looking for HDSP cards : 
Card 0 : VIA 8235 at 0x1000, irq 10 
Card 1 : RME Hammerfall DSP + Multiface at 
0x20000000, irq 11 
Multiface found ! 
1 Hammerfall DSP card found. 
Initializing default presets 

(let's set the latency how RME likes it)

[root@localhost Documents]# setpci -s a.0 0x0d.b 
a8 
[root@localhost Documents]# setpci -s a.0 
0x0d.b=ff 
 
(at this point I played the sound using jack and jack_metro and the thing
sounded like a beautiful...sine tone :-)
<END>

Again, thanks all for your help!

Ivica Ico Bukvic, composer & multimedia sculptor
http://meowing.ccm.uc.edu/~ico/




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

aplay playback-pointer

[Mathieu Rondonneau]

Hi all,

I'm writting an audio driver and i have some trouble.

when i use:
 dd if=file.wav of=/dev/audio0
the oss part of the ALSA driver seams to be used and some sound (not good
sound but noise) are coming out. (the playback_pointer operator is called)

but when i use aplay:
 aplay file.wav
nothing coming out, and the playback_pointer operator is not called.
nothing is called between the start and the stop trigger.

Maybe someone could tell me why the aplay command doesn't call the
playback_pointer.
Do i need to implement some specific functions in order to use aplay?

Thanks for any help.

regards,
Mathieu Rondonneau



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

start stop

[Mathieu Rondonneau]

Hi all,

i'm writting an ALSA driver. I have some trouble with it.

I load the driver and then i play sound with dd (dd if=file.wav
of=/dev/audio0).
all goes right (i have noise rather than sound but, it's another problem).
the trigger call start then play noise, then call stop.

my problem is when i want to play another time, it doesn't work.
the trigger call start then stop then start then stop ...then start and
stop... and doesn't end and doesn't play any sound.

I thank you very much for any help.

regards,
Mathieu Rondonneau



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: start stop resolved

[Mathieu Rondonneau]

Hi all,

I 've resolved my problem.
it was the offset problem in the pointer operator.
the initialisation was not right.

Have a nice day.

Mathieu Rondonneau


----- Original Message ----- 
From: "Mathieu Rondonneau" <mathieu.rondonneau@polymtl.ca>
To: <alsa-devel@lists.sourceforge.net>
Cc: "Mathieu Rondonneau" <mathieu.rondonneau@polymtl.ca>
Sent: Monday, April 12, 2004 10:45 AM
Subject: [Alsa-devel] start stop


> Hi all,
>
> i'm writting an ALSA driver. I have some trouble with it.
>
> I load the driver and then i play sound with dd (dd if=file.wav
> of=/dev/audio0).
> all goes right (i have noise rather than sound but, it's another problem).
> the trigger call start then play noise, then call stop.
>
> my problem is when i want to play another time, it doesn't work.
> the trigger call start then stop then start then stop ...then start and
> stop... and doesn't end and doesn't play any sound.
>
> I thank you very much for any help.
>
> regards,
> Mathieu Rondonneau
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
>



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: start stop

[Jaroslav Kysela]

On Mon, 12 Apr 2004, Mathieu Rondonneau wrote:

> Hi all,
> 
> i'm writting an ALSA driver. I have some trouble with it.
> 
> I load the driver and then i play sound with dd (dd if=file.wav
> of=/dev/audio0).
> all goes right (i have noise rather than sound but, it's another problem).
> the trigger call start then play noise, then call stop.
> 
> my problem is when i want to play another time, it doesn't work.
> the trigger call start then stop then start then stop ...then start and
> stop... and doesn't end and doesn't play any sound.

Your driver probably forget to acknowledge the transfer with the aplay 
settings. Check if snd_pcm_period_elapsed() is called from your interrupt 
handler.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: aplay playback-pointer

[Clemens Ladisch]

Mathieu Rondonneau wrote:
> I'm writting an audio driver and i have some trouble.
>
> when i use:
>  dd if=file.wav of=/dev/audio0
> the oss part of the ALSA driver seams to be used and some sound (not good
> sound but noise) are coming out. (the playback_pointer operator is called)
>
> but when i use aplay:
>  aplay file.wav
> nothing coming out, and the playback_pointer operator is not called.
> nothing is called between the start and the stop trigger.

Do you call snd_pcm_period_elapes() in your interrupt routine?


Regards,
Clemens




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

aplay noise

[Mathieu Rondonneau]

Hi all,

thanks for your answers.

I have another problem with my driver... another one ;)

When i try to play a sound with aplay, there is an horrible noise like: 
"tatatatatatatat" (like gun shoots)

I don't understand why.
I'm trying to playback a wav file, but i hear some strange noise, not the
data corresponding to the wav file.
I compared the data of the wav file and the data in the copy operator
(before they sent to the codec). They seam to be the same.

This is what the aplay -v tell me, maybe it can help.
 
aplay -v voice-8k-16bit-stereo.wav

Playing WAVE 'voice-8k-16bit-stereo.wav' : 
Signed 16 bit Little Endian, Rate 8000 Hz, Stereo

Plug PCM: Hardware PCM card 0 'codec a ' device 0 subdevice 0

Its setup is:
stream      : PLAYBACK
access       : RW_INTERLEAVED                          
format       : S16_LE                                  
subformat    : STD                                     
channels     : 2                                       
rate         : 8000                                    
exact rate   : 8000 (8000/1)                           
msbits       : 16                                      
buffer_size  : 16384                                   
period_size  : 2048                                    
period_time  : 256000                                  
tick_time    : 10000                                   
tstamp_mode  : NONE                                    
period_step  : 1                                       
sleep_min    : 0                                       
avail_min    : 2048                                    
xfer_align   : 2048                                    
start_threshold  : 16384                               
stop_threshold   : 16384                               
silence_threshold: 0 
silence_size : 0                                     
boundary     : 1073741824    

Thank you very much for any help.
regards,

Mathieu



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

arecord wav file, buffer different

[Mathieu Rondonneau]

I all,

I have some problem writing an ALSA driver:

When i use arecord:
arecord -d 10 -r 8000 -f S16_LE -t wav -c 1 test.wav

the data area of the wav file (test.wav) is filled with 0.
I compared the data of the wav file and the data of the capture buffer:
They are different, the buffer is filled with audio datas.

Why my test.wav file is filed with zero?

Any ideas?

Thanks in advance.

regards,
Mahtieu



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: arecord wav file, buffer different

[Clemens Ladisch]

Mathieu Rondonneau wrote:
> I have some problem writing an ALSA driver:
>
> When i use arecord:
> arecord -d 10 -r 8000 -f S16_LE -t wav -c 1 test.wav
>
> the data area of the wav file (test.wav) is filled with 0.
> I compared the data of the wav file and the data of the capture buffer:
> They are different, the buffer is filled with audio datas.

Probably the pointer callback returns wrong data.


HTH
Clemens




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!

[Russell King]

On Sun, Apr 11, 2004 at 09:39:43PM -0400, Ivica Ico Bukvic wrote:
> Hi all! Great news! I managed to fix the issue in Linux. As I suspected it
> was the same problem like in Windows after suspend as the distortion was
> similar.

Don't think the problem is 100% solved just yet - there's still work
to do.

You haven't said which kernel version you're using to test this out
on; 2.6.5 contains some fixes for the CB1410 in these areas, and it
would be useful to know if these are working.

So, as per my previous mail and at risk of sounding like a stuck
record^wCD, which kernel version are you using for this test?

Have you also tried only changing a limited subset of these
registers?  The reason this is important is that just immitating
the working scenario out right doesn't really tell us very much.

You should be able to tweak these while the card is playing, so
you could try setting them all to the "working" state, play back
the audio, and then try undoing each change individually.

> 2) PREFERRED: hdsp driver needs to adjust the cardbus controller latency

No.  Drivers should not fiddle with other parts of the system they
don't own, and the HDSP driver does not own the cardbus controller.
I suspect that the CB1410 quirk needs to force the latency timer at
startup.

> 3) FOR FURTHER INVESTIGATION: Does linux hdsp driver force the f0 value upon
> the 0x81 register or is it that in Linux one simply cannot select d0 value
> for whatever reason

I suspect it may be caused by using a byte access to a longword-sized
register.  0x81 is supposed to be accessed via:

setpci -s a.0 0x80.l

which of course means its bits 8 to 15.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!

[David Hinds]

On Mon, Apr 12, 2004 at 08:28:01AM +0100, Russell King wrote:
> 
> > 3) FOR FURTHER INVESTIGATION: Does linux hdsp driver force the f0
> > value upon the 0x81 register or is it that in Linux one simply
> > cannot select d0 value for whatever reason
> 
> I suspect it may be caused by using a byte access to a longword-sized
> register.  0x81 is supposed to be accessed via:
> 
> setpci -s a.0 0x80.l
> 
> which of course means its bits 8 to 15.

I don't think so; I'm not sure what the PCI spec has to say about it,
but I have not had problems doing byte reads/writes for longer PCI
configuration registers.  Bit 9 of the sysctl register for the TI 1410
is "socket activity"; it is read only and is cleared after each read.
The key change is setting bit 14 (enable upstream burst reads).

Regarding the register at 0xc9, I don't think that is defined in any
TI bridge data sheet; it is in a "reserved" range.

-- Dave

Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!

[Russell King]

On Mon, Apr 12, 2004 at 02:08:17AM -0700, David Hinds wrote:
> I don't think so; I'm not sure what the PCI spec has to say about it,

Yup, you're right.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

RE: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!

[Ivica Ico Bukvic]

> Don't think the problem is 100% solved just yet - there's still work
> to do.
> 
> You haven't said which kernel version you're using to test this out
> on; 2.6.5 contains some fixes for the CB1410 in these areas, and it
> would be useful to know if these are working.
> 
> So, as per my previous mail and at risk of sounding like a stuck
> record^wCD, which kernel version are you using for this test?

Sorry :-) Mandrake Community 10.0 using the 2.6.3 kernel with a patch to fix
the freezing when probing for the pcmcia card on this particular notebook
(see: http://www.muru.com/linux/amd64/).
 
> Have you also tried only changing a limited subset of these
> registers?  The reason this is important is that just immitating
> the working scenario out right doesn't really tell us very much.

Tried various combinations in Windows and only using the 2 in combination
worked. I will test further in Linux if you like when I get the chance. But
as of right now I have a hunch that the same behavior will be observed in
Linux as one value enables burst stuff, while the other value when changed
also introduced distortion (micro-silence between buffers) in Windows if any
other value was used than 0x04.

> You should be able to tweak these while the card is playing, so
> you could try setting them all to the "working" state, play back
> the audio, and then try undoing each change individually.

Will do. I did that with the latency and it still worked for the
before-mentioned reasons but the preferred behavior would be having it at
0xff as that is how the Win driver behaves. However, changing the latency
on-the-fly while JACK audio server and audio is running results in corrupted
audio and JACK needs to be restarted (this is most likely issue with the
fact I was using JACK).

> > 2) PREFERRED: hdsp driver needs to adjust the cardbus controller latency
> 
> No.  Drivers should not fiddle with other parts of the system they
> don't own, and the HDSP driver does not own the cardbus controller.
> I suspect that the CB1410 quirk needs to force the latency timer at
> startup.

Well, in Windows the latency on the controller is 0x20 and then when the
cardbus soundcard (RME) is inserted it is changed into 0xFF. Matthias, the
support guy from RME also confirmed this behavior (that their driver is
changing the value upon connection).
 
> > 3) FOR FURTHER INVESTIGATION: Does linux hdsp driver force the f0 value
> upon
> > the 0x81 register or is it that in Linux one simply cannot select d0
> value
> > for whatever reason
> 
> I suspect it may be caused by using a byte access to a longword-sized
> register.  0x81 is supposed to be accessed via:
> 
> setpci -s a.0 0x80.l
> 
> which of course means its bits 8 to 15.

Sounds like that was most likely it. I will test it as soon as I get the
chance to do so.

Thank you very much for all your help!

Best wishes,

Ico

Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!

[Russell King]

On Mon, Apr 12, 2004 at 10:40:59AM -0400, Ivica Ico Bukvic wrote:
> Sorry :-) Mandrake Community 10.0 using the 2.6.3 kernel with a patch to fix
> the freezing when probing for the pcmcia card on this particular notebook
> (see: http://www.muru.com/linux/amd64/).

Pavel's fix isn't really a fix, it's more a work-around.  If we keep
increasing PCIBIOS_MIN_CARDBUS_IO until we hit 0xffff, everyones
system stops working.

The problem there will be that there's some IO registers between 0x4000
and 0x5000 which the BIOS wants access to, but the kernel didn't know
that they existed.

In any case, 2.6.3 does not contain the patches for CB1410, so chances
are that your problem is already half solved in 2.6.5.

Ok, so the action plan is:

- set 0xc9 to 0x04 for CB1410 (and others?)
- find a reasonable solution to the latency timer, maybe just setting it
  to 0xff when we detect the bridge.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!

[Daniel Ritz]

On Monday 12 April 2004 16:53, Russell King wrote:
> On Mon, Apr 12, 2004 at 10:40:59AM -0400, Ivica Ico Bukvic wrote:
> > Sorry :-) Mandrake Community 10.0 using the 2.6.3 kernel with a patch to fix
> > the freezing when probing for the pcmcia card on this particular notebook
> > (see: http://www.muru.com/linux/amd64/).
> 
> Pavel's fix isn't really a fix, it's more a work-around.  If we keep
> increasing PCIBIOS_MIN_CARDBUS_IO until we hit 0xffff, everyones
> system stops working.
> 
> The problem there will be that there's some IO registers between 0x4000
> and 0x5000 which the BIOS wants access to, but the kernel didn't know
> that they existed.
> 
> In any case, 2.6.3 does not contain the patches for CB1410, so chances
> are that your problem is already half solved in 2.6.5.
> 
> Ok, so the action plan is:
> 
> - set 0xc9 to 0x04 for CB1410 (and others?)

EnE datasheet says it's also available in EnE 1211, 1225, 1420.
and since they are TI clones why not for the TI's too?


ico,

one question. when you insert the card in windows it changes
the latency timer at 0x0d to 0xff. what is the value at 0x1b? is it also 0xff?
if it's not 0xff can you try changing it to 0xff and set 0xc9 to 0x06?
i ask 'cos your screenshot w/o the card has it set to 0x00. and i have
the feeling that the bit at 0xc9 has something to do with the latency
timers....

rgds
-daniel

Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!

[Russell King]

On Mon, Apr 12, 2004 at 05:31:20PM +0200, Daniel Ritz wrote:
> EnE datasheet says it's also available in EnE 1211, 1225, 1420.
> and since they are TI clones why not for the TI's too?

Because the register supposedly does not exist on TI - it's likely to be
EnE specific.

I'm willing to bet that TI chips will behave as expected without touching
0xc9 at all.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!

[Tim Blechmann]

hi russell and others ...

i'm curious, since our discussion got quiet in the last few days ... if
ico was able to solve his problem by altering cardbus registers, but my
hdsp works fine with windows with the same register settings on the
cardbus bridge that won't work with linux ... what does this imply to my
setup? do you have any idea, where could be the problem?

my system doesn't have the pci bus connected directly to the cardbus
bridge, but there is a pci-to-pci bridge in between ... i found a
register difference between the windows and the linux settings in that
... but changing this register doesn't change the behaviour of the hdsp
:-(

cheers...

 Tim                          mailto:TimBlechmann@gmx.de
                              ICQ: 96771783
--
The only people for me are the mad ones, the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn,
burn, like fabulous yellow roman candles exploding like spiders across
the stars and in the middle you see the blue centerlight pop and
everybody goes "Awww!"
                                                          Jack Kerouac

Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!

[Tim Blechmann]

hi all,

i installed windows to check if there is anything happening to the
cardbus registers when working on a supported system... the cardbus
registers, beside the pci registers, are the same as on the linux system
... 
i haven't been able to play back some sounds, because rme's driver disc
only contains the win2k driver ...

i have no idea, what this might tell us ... it's not a very good feeling
if someone who seem to have the same problem as yourself finds the
reason for his problem, but it doesn't seem to be the reason of your
problem ... anyway, let's hope the best...

cheers...

 Tim                          mailto:TimBlechmann@gmx.de
                              ICQ: 96771783
--
The only people for me are the mad ones, the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn,
burn, like fabulous yellow roman candles exploding like spiders across
the stars and in the middle you see the blue centerlight pop and
everybody goes "Awww!"
                                                          Jack Kerouac

Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!

[Tim Blechmann]

hi ico, hi russell

first of all, congratulations that you, ico, got your hdsp working ...
anyway the registers you were changing have no effect on my setup ... they are zero:

your configuration:
> [root@localhost 00]# hexdump 
> -v /proc/bus/pci/00/0a.0 
> 0000000 1524 1410 0007 0210 0000 0607 a808 0002 
> 0000010 f000 ffe7 00a0 0200 0200 b005 e000 ffe7 
> 0000020 e000 ffe7 0000 2000 f000 203f 5000 0000 
> 0000030 50fc 0000 5400 0000 54fc 0000 010b 05c0 
> 0000040 161f 2032 0001 0000 0000 0000 0000 0000 
> 0000050 0000 0000 0000 0000 0000 0000 0000 0000 
> 0000060 0000 0000 0000 0000 0000 0000 0000 0000 
> 0000070 0000 0000 0000 0000 0000 0000 0000 0000 
> 0000080 9021 4044 0000 0000 0000 0000 1002 0100 
> 0000090 82c0 6044 0000 0000 0000 0000 0000 0000 
> 00000a0 0001 fe01 0000 00c0 0000 0000 001f 0000 
> 00000b0 0000 0000 0000 0000 0000 0000 0000 0000 
> 00000c0 1000 0000 0080 0080 0600 1008 0000 0000 
> 00000d0 0000 0000 0000 0000 0000 0000 0000 0000 
> 00000e0 0000 0000 0000 0000 0000 0000 0000 0000 
> 00000f0 0000 0000 0000 0000 0000 0000 0000 0000 
> 0000100 

mine: (kernel 2.6.4-ck1 and 2.6.5-gentoo have the same results)
bash-2.05b# hexdump -v /proc/bus/pci/02/00.1
0000000 1217 6933 0087 0410 0001 0607 a800 0082
0000010 1000 2000 00a0 0200 0702 b00a 0000 20c0
0000020 f000 20ff 0000 2100 f000 213f 4c01 0000
0000030 4cfd 0000 5001 0000 50fd 0000 0200 0580
0000040 1025 0019 0001 0000 0000 0000 0000 0000
0000050 0000 0000 0000 0000 0000 0000 0000 0000
0000060 0000 0000 0000 0000 0000 0000 0000 0000
0000070 0000 0000 0000 0000 0000 0000 0000 0000
0000080 0000 0000 0000 0000 0000 0000 0000 0000
0000090 23bf 4c00 03e8 8242 0000 2050 0000 0000
00000a0 0001 fe02 4000 00c0 0000 0000 0000 0000
00000b0 0000 0000 0000 0000 0000 0000 0000 0000
00000c0 0000 0000 0000 0000 0000 0000 0000 0000
00000d0 0000 0000 0000 0000 0000 0000 0000 0000
00000e0 0000 0000 0000 0000 0000 0000 0000 0000
00000f0 0000 0000 0000 0000 0000 0000 0000 0000
0000100

after plugging the hdsp in:
> bash-2.05b# hexdump -v /proc/bus/pci/02/00.1
> 0000000 1217 6933 0087 0410 0001 0607 a800 0082
> 0000010 1000 2000 00a0 0200 0702 b00a 0000 20c0
> 0000020 f000 20ff 0000 2100 f000 213f 4c01 0000
> 0000030 4cfd 0000 5001 0000 50fd 0000 0200 0500
> 0000040 1025 0019 0001 0000 0000 0000 0000 0000
> 0000050 0000 0000 0000 0000 0000 0000 0000 0000
> 0000060 0000 0000 0000 0000 0000 0000 0000 0000
> 0000070 0000 0000 0000 0000 0000 0000 0000 0000
> 0000080 0000 0000 0000 0000 0000 0000 0000 0000
> 0000090 23bf 4c00 03e8 8242 0000 2050 0000 0000
> 00000a0 0001 fe02 4000 00c0 0000 0000 0000 0000
> 00000b0 0000 0000 0000 0000 0000 0000 0000 0000
> 00000c0 0000 0000 0000 0000 0000 0000 0000 0000
> 00000d0 0000 0000 0000 0000 0000 0000 0000 0000
> 00000e0 0000 0000 0000 0000 0000 0000 0000 0000
> 00000f0 0000 0000 0000 0000 0000 0000 0000 0000
> 0000100

the only register that's changing after plugging the hdsp in is the MIN_GNT register ... (from 0x80 to 0x00)
the registers ico changed are 00 on my system ... possibly i'll have to install windows on my machine to figure out, if i have the same problem as ico ... 

cheers...

 Tim                          mailto:TimBlechmann@gmx.de
                              ICQ: 96771783
--
The only people for me are the mad ones, the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn,
burn, like fabulous yellow roman candles exploding like spiders across
the stars and in the middle you see the blue centerlight pop and
everybody goes "Awww!"
                                                          Jack Kerouac



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!

[Russell King]

On Mon, Apr 12, 2004 at 01:02:36PM +0200, Tim Blechmann wrote:
> first of all, congratulations that you, ico, got your hdsp working ...

Only the first 0x48 registers are defined by the base specification;
the rest are chip and/or manufacturer specific.

The registers which Ico is changing are specific to the ENE CB1410,
which are a clone of the TI chips.

Your cardbus bridge isn't a clone of TI, so I wouldn't expect the
same fix to work for you.

However, we now have some of the clues, so...

PS, in your first mail I have on this subject, you mentioned someone
called "Timothy" who had the same problem, and was using Red Hat with
a TI bridge.  I don't seem to have any responses from him, and it would
be good to get some feedback from him as well.  Specifically whether
stock 2.6.5 works or exhibits the same problem.

Stock 2.6.5 with TI bridges should already set 0x81 to 0xd0, and they
don't have the other register at 0xc9.  This only leaves the cardbus
bridge latency timer.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!

[Tim Blechmann]

> Only the first 0x48 registers are defined by the base specification;
> the rest are chip and/or manufacturer specific.
i see ...

> The registers which Ico is changing are specific to the ENE CB1410,
> which are a clone of the TI chips.
> 
> Your cardbus bridge isn't a clone of TI, so I wouldn't expect the
> same fix to work for you.
:-(
do you want me to install windows and have a look at my register settings on a working setup? since my problem might be a different one, i just want to make sure that its neccessary that i install windows ... i'd have to back up a lot of stuff, so it would take some time...
 
> PS, in your first mail I have on this subject, you mentioned someone
> called "Timothy" who had the same problem, and was using Red Hat with
> a TI bridge.  I don't seem to have any responses from him, and it i forwarded this mail to him ... i hope he will respond, soon...

cheers...

 Tim                          mailto:TimBlechmann@gmx.de
                              ICQ: 96771783
--
The only people for me are the mad ones, the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn,
burn, like fabulous yellow roman candles exploding like spiders across
the stars and in the middle you see the blue centerlight pop and
everybody goes "Awww!"
                                                          Jack Kerouac

Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!

[Daniel Ritz]

On Monday 12 April 2004 03:39, Ivica Ico Bukvic wrote: 
> **I've noted that when I use:
> 
> setpci -s a.0 0x81.b
> 
> after changing the value to 0xd0 (with setpci -s a.0 0x81.b=d0) it would
> tell me that it was equal to f0, yet the "hexdump -v /proc/bus/pci/00/0a.0"
> would tell me it was d0 after all (see the log below).
> 

it's a single bit change from 0xd0 to 0xf0. it's bit 13 of the system control
register at 0x80. it's the socket activity bit that is read-clear. this means
writing to it has no effect, reading it clears the content. so the behavior
is normal...