RE: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- First good news

All of lore.kernel.org
 help / color / mirror / Atom feed

* RE: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- First good news
@ 2004-04-10  1:47 Daniel Ritz
  2004-04-10  3:30   ` Ivica Ico Bukvic
  0 siblings, 1 reply; 34+ messages in thread
From: Daniel Ritz @ 2004-04-10  1:47 UTC (permalink / raw)
  To: Ivica Ico Bukvic; +Cc: linux-kernel

you can get the same output with
	hexdump -v /proc/bus/pci/BUS/DEVICE
where BUS/DEVICE is the CB controller. eg. 00/09.0

about the bits:
- at 81h, from D0 to 90: this is part of the system control register. the bit
  that changed is "Memory read burst enable upstream"
- at c9h, from 04 to 06: this is an undocumented test register. TI just says
  reserved, EnE says test register, for the bit that changed it adds the 
  comment TLTEnable (default to 1). no idea what it is. it _could_ have
  something to do with the cardbus latency timer...you can try to play a bit
  with the latency setting after resume when this bit is set. try writing to
  offset 1Bh, put in at least 40h

to change the bits under linux, use setpci (also good for reading)

about the memory read burst upstream: 2.6 kernels enable it for most of
the TI chips and since 2.6.5 also for some TI clones from EnE (incl. EnE1410).

rgds
-daniel


^ permalink raw reply	[flat|nested] 34+ messages in thread

* RE: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- First good news
  2004-04-10  1:47 [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- First good news Daniel Ritz
@ 2004-04-10  3:30   ` Ivica Ico Bukvic
  0 siblings, 0 replies; 34+ messages in thread
From: Ivica Ico Bukvic @ 2004-04-10  3:30 UTC (permalink / raw)
  To: daniel.ritz
  Cc: 'A list for linux audio users', 'Russell King',
	alsa-devel, linux-kernel, linux-pcmcia,
	'Thomas Charbonnel', ccheney, 'Tim Blechmann'

Thank you very much for an exhaustive breakdown of this issue! Your
assistance has been truly helpful!

I am aware that this burst stuff should be enabled on the 2.6 kernel,
however I am still getting bad results.

The 06 to 04 may be the critical element as even when I have everything
properly running in Win32, when I alter this number the distortion returns
(it is almost like an azimuth on old analogue tape decks that one would
adjust using screwdriver in order to successfully load a program into a
Commodore64 or the legendary Sinclair ZX Spectrum :-).

If I do figure out the problem in Linux and find out that a particular
register is the issue, how can I make my linux box adjust this register at
boot-time (a simple hack-like script in a form of a service comes to mind
but I was hoping to perhaps see a more universal solution if possible)?

Best wishes,

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

> -----Original Message-----
> From: Daniel Ritz [mailto:daniel.ritz@gmx.ch]
> Sent: Friday, April 09, 2004 9:48 PM
> To: Ivica Ico Bukvic
> Cc: linux-kernel
> Subject: RE: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion
> -- First good news
> 
> you can get the same output with
> 	hexdump -v /proc/bus/pci/BUS/DEVICE
> where BUS/DEVICE is the CB controller. eg. 00/09.0
> 
> about the bits:
> - at 81h, from D0 to 90: this is part of the system control register. the
> bit
>   that changed is "Memory read burst enable upstream"
> - at c9h, from 04 to 06: this is an undocumented test register. TI just
> says
>   reserved, EnE says test register, for the bit that changed it adds the
>   comment TLTEnable (default to 1). no idea what it is. it _could_ have
>   something to do with the cardbus latency timer...you can try to play a
> bit
>   with the latency setting after resume when this bit is set. try writing
> to
>   offset 1Bh, put in at least 40h
> 
> to change the bits under linux, use setpci (also good for reading)
> 
> about the memory read burst upstream: 2.6 kernels enable it for most of
> the TI chips and since 2.6.5 also for some TI clones from EnE (incl.
> EnE1410).
> 
> rgds
> -daniel

^ permalink raw reply	[flat|nested] 34+ messages in thread

* RE: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- First good news
@ 2004-04-10  3:30   ` Ivica Ico Bukvic
  0 siblings, 0 replies; 34+ messages in thread
From: Ivica Ico Bukvic @ 2004-04-10  3:30 UTC (permalink / raw)
  To: daniel.ritz
  Cc: 'A list for linux audio users', 'Russell King',
	alsa-devel, linux-kernel, linux-pcmcia,
	'Thomas Charbonnel', ccheney, 'Tim Blechmann'

Thank you very much for an exhaustive breakdown of this issue! Your
assistance has been truly helpful!

I am aware that this burst stuff should be enabled on the 2.6 kernel,
however I am still getting bad results.

The 06 to 04 may be the critical element as even when I have everything
properly running in Win32, when I alter this number the distortion returns
(it is almost like an azimuth on old analogue tape decks that one would
adjust using screwdriver in order to successfully load a program into a
Commodore64 or the legendary Sinclair ZX Spectrum :-).

If I do figure out the problem in Linux and find out that a particular
register is the issue, how can I make my linux box adjust this register at
boot-time (a simple hack-like script in a form of a service comes to mind
but I was hoping to perhaps see a more universal solution if possible)?

Best wishes,

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

> -----Original Message-----
> From: Daniel Ritz [mailto:daniel.ritz@gmx.ch]
> Sent: Friday, April 09, 2004 9:48 PM
> To: Ivica Ico Bukvic
> Cc: linux-kernel
> Subject: RE: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion
> -- First good news
> 
> you can get the same output with
> 	hexdump -v /proc/bus/pci/BUS/DEVICE
> where BUS/DEVICE is the CB controller. eg. 00/09.0
> 
> about the bits:
> - at 81h, from D0 to 90: this is part of the system control register. the
> bit
>   that changed is "Memory read burst enable upstream"
> - at c9h, from 04 to 06: this is an undocumented test register. TI just
> says
>   reserved, EnE says test register, for the bit that changed it adds the
>   comment TLTEnable (default to 1). no idea what it is. it _could_ have
>   something to do with the cardbus latency timer...you can try to play a
> bit
>   with the latency setting after resume when this bit is set. try writing
> to
>   offset 1Bh, put in at least 40h
> 
> to change the bits under linux, use setpci (also good for reading)
> 
> about the memory read burst upstream: 2.6 kernels enable it for most of
> the TI chips and since 2.6.5 also for some TI clones from EnE (incl.
> EnE1410).
> 
> rgds
> -daniel

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- First good news
  2004-04-10  3:30   ` Ivica Ico Bukvic
  (?)
@ 2004-04-11 13:25   ` Russell King
  2004-04-11 16:08     ` Tim Blechmann
  -1 siblings, 1 reply; 34+ messages in thread
From: Russell King @ 2004-04-11 13:25 UTC (permalink / raw)
  To: Ivica Ico Bukvic
  Cc: daniel.ritz, 'Thomas Charbonnel', ccheney, linux-pcmcia,
	alsa-devel, linux-kernel, 'Tim Blechmann'

(Note: I've dropped one of the mailing lists from the CC line because
they appear to have zero interest in my messages.)

On Fri, Apr 09, 2004 at 11:30:31PM -0400, Ivica Ico Bukvic wrote:
> I am aware that this burst stuff should be enabled on the 2.6 kernel,
> however I am still getting bad results.

Are you saying that you have tried the 2.6.5 kernel?

> The 06 to 04 may be the critical element as even when I have everything
> properly running in Win32, when I alter this number the distortion returns

$ setpci -s a.0 0xc9.b

will display the value of this register under Linux, and:

$ setpci -s a.0 0xc9.b=value

will set it to the desired value.  However, check that a.0 is the
cardbus bridge first by using:

$ lspci

> If I do figure out the problem in Linux and find out that a particular
> register is the issue, how can I make my linux box adjust this register at
> boot-time (a simple hack-like script in a form of a service comes to mind
> but I was hoping to perhaps see a more universal solution if possible)?

The correct solution is to put a quirk into the kernels yenta driver,
but we'd need the results from your testing first.

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- First good news
  2004-04-11 13:25   ` Russell King
@ 2004-04-11 16:08     ` Tim Blechmann
  2004-04-11 23:45       ` Daniel Ritz
  0 siblings, 1 reply; 34+ messages in thread
From: Tim Blechmann @ 2004-04-11 16:08 UTC (permalink / raw)
  To: Russell King
  Cc: Ivica Ico Bukvic, daniel.ritz, 'Thomas Charbonnel',
	ccheney, linux-pcmcia, alsa-devel, linux-kernel

hi all,

> > The 06 to 04 may be the critical element as even when I have
> > everything properly running in Win32, when I alter this number the
> > distortion returns
> 
> $ setpci -s a.0 0xc9.b
> 
> will display the value of this register under Linux, and:
> 
> $ setpci -s a.0 0xc9.b=value
i tried to read these registers on my cardbus bridge but on my system
the registers are zero (00) ... 
i tried to set these registers to the values ico had on his machines,
but it seems that i'm not able to set them ... if i read the registers
after setting them, they are still zero ...
is it possible to find out what this register is actually representing?

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- First good news
  2004-04-11 16:08     ` Tim Blechmann
@ 2004-04-11 23:45       ` Daniel Ritz
  2004-04-12  1:39           ` Ivica Ico Bukvic
  0 siblings, 1 reply; 34+ messages in thread
From: Daniel Ritz @ 2004-04-11 23:45 UTC (permalink / raw)
  To: Tim Blechmann
  Cc: Ivica Ico Bukvic, 'Thomas Charbonnel', ccheney,
	linux-pcmcia, linux-kernel, Russell King

On Sunday 11 April 2004 18:08, Tim Blechmann wrote:
> hi all,
> 
> > > The 06 to 04 may be the critical element as even when I have
> > > everything properly running in Win32, when I alter this number the
> > > distortion returns
> > 
> > $ setpci -s a.0 0xc9.b
> > 
> > will display the value of this register under Linux, and:
> > 
> > $ setpci -s a.0 0xc9.b=value
> i tried to read these registers on my cardbus bridge but on my system
> the registers are zero (00) ... 
> i tried to set these registers to the values ico had on his machines,
> but it seems that i'm not able to set them ... if i read the registers
> after setting them, they are still zero ...

that register is specific to TI/EnE bridges. if i remember correctly, you
have a o2micro 6933, right?


^ permalink raw reply	[flat|nested] 34+ messages in thread

* RE: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!
  2004-04-11 23:45       ` Daniel Ritz
@ 2004-04-12  1:39           ` Ivica Ico Bukvic
  0 siblings, 0 replies; 34+ messages in thread
From: Ivica Ico Bukvic @ 2004-04-12  1:39 UTC (permalink / raw)
  To: daniel.ritz, 'Tim Blechmann'
  Cc: 'Thomas Charbonnel', ccheney, linux-pcmcia, linux-kernel,
	'Russell King', alsa-devel

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* RE: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!
@ 2004-04-12  1:39           ` Ivica Ico Bukvic
  0 siblings, 0 replies; 34+ messages in thread
From: Ivica Ico Bukvic @ 2004-04-12  1:39 UTC (permalink / raw)
  To: daniel.ritz, 'Tim Blechmann'
  Cc: 'Thomas Charbonnel', ccheney, linux-pcmcia, linux-kernel,
	'Russell King', alsa-devel

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/



^ permalink raw reply	[flat|nested] 34+ messages in thread

* aplay playback-pointer
  2004-04-12  1:39           ` Ivica Ico Bukvic
  (?)
@ 2004-04-12  5:24           ` Mathieu Rondonneau
  2004-04-12 15:45             ` start stop Mathieu Rondonneau
  2004-04-13 16:25             ` aplay playback-pointer Clemens Ladisch
  -1 siblings, 2 replies; 34+ messages in thread
From: Mathieu Rondonneau @ 2004-04-12  5:24 UTC (permalink / raw)
  To: alsa-devel; +Cc: 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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* start stop
  2004-04-12  5:24           ` aplay playback-pointer Mathieu Rondonneau
@ 2004-04-12 15:45             ` Mathieu Rondonneau
  2004-04-12 16:58               ` start stop resolved Mathieu Rondonneau
  2004-04-12 17:59               ` start stop Jaroslav Kysela
  2004-04-13 16:25             ` aplay playback-pointer Clemens Ladisch
  1 sibling, 2 replies; 34+ messages in thread
From: Mathieu Rondonneau @ 2004-04-12 15:45 UTC (permalink / raw)
  To: alsa-devel; +Cc: 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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: start stop resolved
  2004-04-12 15:45             ` start stop Mathieu Rondonneau
@ 2004-04-12 16:58               ` Mathieu Rondonneau
  2004-04-12 17:59               ` start stop Jaroslav Kysela
  1 sibling, 0 replies; 34+ messages in thread
From: Mathieu Rondonneau @ 2004-04-12 16:58 UTC (permalink / raw)
  To: alsa-devel

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: start stop
  2004-04-12 15:45             ` start stop Mathieu Rondonneau
  2004-04-12 16:58               ` start stop resolved Mathieu Rondonneau
@ 2004-04-12 17:59               ` Jaroslav Kysela
  1 sibling, 0 replies; 34+ messages in thread
From: Jaroslav Kysela @ 2004-04-12 17:59 UTC (permalink / raw)
  To: Mathieu Rondonneau; +Cc: alsa-devel

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: aplay playback-pointer
  2004-04-12  5:24           ` aplay playback-pointer Mathieu Rondonneau
  2004-04-12 15:45             ` start stop Mathieu Rondonneau
@ 2004-04-13 16:25             ` Clemens Ladisch
  2004-04-14  3:06               ` aplay noise Mathieu Rondonneau
  2004-04-17 21:06               ` arecord wav file, buffer different Mathieu Rondonneau
  1 sibling, 2 replies; 34+ messages in thread
From: Clemens Ladisch @ 2004-04-13 16:25 UTC (permalink / raw)
  To: Mathieu Rondonneau; +Cc: alsa-devel

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* aplay noise
  2004-04-13 16:25             ` aplay playback-pointer Clemens Ladisch
@ 2004-04-14  3:06               ` Mathieu Rondonneau
  2004-04-17 21:06               ` arecord wav file, buffer different Mathieu Rondonneau
  1 sibling, 0 replies; 34+ messages in thread
From: Mathieu Rondonneau @ 2004-04-14  3:06 UTC (permalink / raw)
  To: alsa-devel

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* arecord wav file, buffer different
  2004-04-13 16:25             ` aplay playback-pointer Clemens Ladisch
  2004-04-14  3:06               ` aplay noise Mathieu Rondonneau
@ 2004-04-17 21:06               ` Mathieu Rondonneau
  2004-04-20  9:08                 ` Clemens Ladisch
  1 sibling, 1 reply; 34+ messages in thread
From: Mathieu Rondonneau @ 2004-04-17 21:06 UTC (permalink / raw)
  To: alsa-devel

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: arecord wav file, buffer different
  2004-04-17 21:06               ` arecord wav file, buffer different Mathieu Rondonneau
@ 2004-04-20  9:08                 ` Clemens Ladisch
  0 siblings, 0 replies; 34+ messages in thread
From: Clemens Ladisch @ 2004-04-20  9:08 UTC (permalink / raw)
  To: Mathieu Rondonneau; +Cc: alsa-devel

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!
  2004-04-12  1:39           ` Ivica Ico Bukvic
  (?)
  (?)
@ 2004-04-12  7:28           ` Russell King
  2004-04-12  9:08             ` David Hinds
  2004-04-12 14:40               ` Ivica Ico Bukvic
  -1 siblings, 2 replies; 34+ messages in thread
From: Russell King @ 2004-04-12  7:28 UTC (permalink / raw)
  To: Ivica Ico Bukvic
  Cc: daniel.ritz, 'Tim Blechmann', 'Thomas Charbonnel',
	ccheney, linux-pcmcia, alsa-devel, linux-kernel

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!
  2004-04-12  7:28           ` [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED! Russell King
@ 2004-04-12  9:08             ` David Hinds
  2004-04-12  9:27               ` Russell King
  2004-04-12 14:40               ` Ivica Ico Bukvic
  1 sibling, 1 reply; 34+ messages in thread
From: David Hinds @ 2004-04-12  9:08 UTC (permalink / raw)
  To: Ivica Ico Bukvic, daniel.ritz, 'Tim Blechmann',
	'Thomas Charbonnel', ccheney, linux-pcmcia, alsa-devel,
	linux-kernel

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!
  2004-04-12  9:08             ` David Hinds
@ 2004-04-12  9:27               ` Russell King
  0 siblings, 0 replies; 34+ messages in thread
From: Russell King @ 2004-04-12  9:27 UTC (permalink / raw)
  To: David Hinds
  Cc: Ivica Ico Bukvic, daniel.ritz, 'Tim Blechmann',
	'Thomas Charbonnel', ccheney, linux-pcmcia, alsa-devel,
	linux-kernel

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* RE: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!
  2004-04-12  7:28           ` [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED! Russell King
@ 2004-04-12 14:40               ` Ivica Ico Bukvic
  2004-04-12 14:40               ` Ivica Ico Bukvic
  1 sibling, 0 replies; 34+ messages in thread
From: Ivica Ico Bukvic @ 2004-04-12 14:40 UTC (permalink / raw)
  To: 'Russell King'
  Cc: daniel.ritz, 'Tim Blechmann', 'Thomas Charbonnel',
	ccheney, linux-pcmcia, alsa-devel, linux-kernel

> 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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* RE: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!
@ 2004-04-12 14:40               ` Ivica Ico Bukvic
  0 siblings, 0 replies; 34+ messages in thread
From: Ivica Ico Bukvic @ 2004-04-12 14:40 UTC (permalink / raw)
  To: 'Russell King'
  Cc: daniel.ritz, 'Tim Blechmann', 'Thomas Charbonnel',
	ccheney, linux-pcmcia, alsa-devel, linux-kernel

> 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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!
  2004-04-12 14:40               ` Ivica Ico Bukvic
  (?)
@ 2004-04-12 14:53               ` Russell King
  2004-04-12 15:31                 ` Daniel Ritz
  -1 siblings, 1 reply; 34+ messages in thread
From: Russell King @ 2004-04-12 14:53 UTC (permalink / raw)
  To: Ivica Ico Bukvic
  Cc: daniel.ritz, 'Tim Blechmann', 'Thomas Charbonnel',
	ccheney, linux-pcmcia, alsa-devel, linux-kernel

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!
  2004-04-12 14:53               ` Russell King
@ 2004-04-12 15:31                 ` Daniel Ritz
  2004-04-12 15:38                   ` Russell King
  0 siblings, 1 reply; 34+ messages in thread
From: Daniel Ritz @ 2004-04-12 15:31 UTC (permalink / raw)
  To: Russell King, Ivica Ico Bukvic
  Cc: 'Tim Blechmann', 'Thomas Charbonnel', ccheney,
	linux-pcmcia, alsa-devel, linux-kernel

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!
  2004-04-12 15:31                 ` Daniel Ritz
@ 2004-04-12 15:38                   ` Russell King
  2004-04-12 18:03                     ` Daniel Ritz
  2004-04-14 13:41                     ` Tim Blechmann
  0 siblings, 2 replies; 34+ messages in thread
From: Russell King @ 2004-04-12 15:38 UTC (permalink / raw)
  To: Daniel Ritz
  Cc: Ivica Ico Bukvic, 'Tim Blechmann',
	'Thomas Charbonnel', ccheney, linux-pcmcia, alsa-devel,
	linux-kernel

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!
  2004-04-12 15:38                   ` Russell King
@ 2004-04-12 18:03                     ` Daniel Ritz
  2004-04-14 13:41                     ` Tim Blechmann
  1 sibling, 0 replies; 34+ messages in thread
From: Daniel Ritz @ 2004-04-12 18:03 UTC (permalink / raw)
  To: Russell King
  Cc: Ivica Ico Bukvic, 'Tim Blechmann',
	'Thomas Charbonnel', ccheney, linux-pcmcia, linux-kernel

On Monday 12 April 2004 17:38, Russell King wrote:
> 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.

you win. just booted my TI1410 laptop . 0xc9 is 0 and read-only.
so the EnE's are not 100% TI clone...


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!
  2004-04-12 15:38                   ` Russell King
  2004-04-12 18:03                     ` Daniel Ritz
@ 2004-04-14 13:41                     ` Tim Blechmann
  1 sibling, 0 replies; 34+ messages in thread
From: Tim Blechmann @ 2004-04-14 13:41 UTC (permalink / raw)
  To: Russell King
  Cc: Daniel Ritz, Ivica Ico Bukvic, 'Thomas Charbonnel',
	ccheney, linux-pcmcia, alsa-devel, linux-kernel

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!
  2004-04-12 14:40               ` Ivica Ico Bukvic
@ 2004-04-12 22:06                 ` Tim Blechmann
  -1 siblings, 0 replies; 34+ messages in thread
From: Tim Blechmann @ 2004-04-12 22:06 UTC (permalink / raw)
  To: Ivica Ico Bukvic
  Cc: 'Russell King', daniel.ritz, 'Thomas Charbonnel',
	ccheney, linux-pcmcia, alsa-devel, linux-kernel

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!
@ 2004-04-12 22:06                 ` Tim Blechmann
  0 siblings, 0 replies; 34+ messages in thread
From: Tim Blechmann @ 2004-04-12 22:06 UTC (permalink / raw)
  To: Ivica Ico Bukvic
  Cc: 'Russell King', daniel.ritz, 'Thomas Charbonnel',
	ccheney, linux-pcmcia, alsa-devel, linux-kernel

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!
  2004-04-12  1:39           ` Ivica Ico Bukvic
@ 2004-04-12 11:02             ` Tim Blechmann
  -1 siblings, 0 replies; 34+ messages in thread
From: Tim Blechmann @ 2004-04-12 11:02 UTC (permalink / raw)
  To: Ivica Ico Bukvic, 'Russell King'
  Cc: daniel.ritz, 'Thomas Charbonnel', ccheney, linux-pcmcia,
	linux-kernel, alsa-devel

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!
@ 2004-04-12 11:02             ` Tim Blechmann
  0 siblings, 0 replies; 34+ messages in thread
From: Tim Blechmann @ 2004-04-12 11:02 UTC (permalink / raw)
  To: Ivica Ico Bukvic, 'Russell King'
  Cc: daniel.ritz, 'Thomas Charbonnel', ccheney, linux-pcmcia,
	linux-kernel, alsa-devel

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


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!
  2004-04-12 11:02             ` Tim Blechmann
  (?)
@ 2004-04-12 10:39             ` Russell King
  2004-04-12 12:09               ` Tim Blechmann
  -1 siblings, 1 reply; 34+ messages in thread
From: Russell King @ 2004-04-12 10:39 UTC (permalink / raw)
  To: Tim Blechmann
  Cc: Ivica Ico Bukvic, 'Thomas Charbonnel', daniel.ritz,
	ccheney, linux-pcmcia, alsa-devel, linux-kernel

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!
  2004-04-12 10:39             ` Russell King
@ 2004-04-12 12:09               ` Tim Blechmann
  0 siblings, 0 replies; 34+ messages in thread
From: Tim Blechmann @ 2004-04-12 12:09 UTC (permalink / raw)
  To: Russell King
  Cc: Ivica Ico Bukvic, 'Thomas Charbonnel', daniel.ritz,
	ccheney, linux-pcmcia, alsa-devel, linux-kernel

> 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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!
  2004-04-12  1:39           ` Ivica Ico Bukvic
@ 2004-04-12 15:19             ` Daniel Ritz
  -1 siblings, 0 replies; 34+ messages in thread
From: Daniel Ritz @ 2004-04-12 15:19 UTC (permalink / raw)
  To: Ivica Ico Bukvic
  Cc: 'Thomas Charbonnel', ccheney, linux-pcmcia, linux-kernel,
	'Russell King', alsa-devel, 'Tim Blechmann',
	David Hinds

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED!
@ 2004-04-12 15:19             ` Daniel Ritz
  0 siblings, 0 replies; 34+ messages in thread
From: Daniel Ritz @ 2004-04-12 15:19 UTC (permalink / raw)
  To: Ivica Ico Bukvic
  Cc: 'Thomas Charbonnel', ccheney, linux-pcmcia, linux-kernel,
	'Russell King', alsa-devel, 'Tim Blechmann',
	David Hinds

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


^ permalink raw reply	[flat|nested] 34+ messages in thread

end of thread, other threads:[~2004-04-20  9:08 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-04-10  1:47 [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- First good news Daniel Ritz
2004-04-10  3:30 ` Ivica Ico Bukvic
2004-04-10  3:30   ` Ivica Ico Bukvic
2004-04-11 13:25   ` Russell King
2004-04-11 16:08     ` Tim Blechmann
2004-04-11 23:45       ` Daniel Ritz
2004-04-12  1:39         ` [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED! Ivica Ico Bukvic
2004-04-12  1:39           ` Ivica Ico Bukvic
2004-04-12  5:24           ` aplay playback-pointer Mathieu Rondonneau
2004-04-12 15:45             ` start stop Mathieu Rondonneau
2004-04-12 16:58               ` start stop resolved Mathieu Rondonneau
2004-04-12 17:59               ` start stop Jaroslav Kysela
2004-04-13 16:25             ` aplay playback-pointer Clemens Ladisch
2004-04-14  3:06               ` aplay noise Mathieu Rondonneau
2004-04-17 21:06               ` arecord wav file, buffer different Mathieu Rondonneau
2004-04-20  9:08                 ` Clemens Ladisch
2004-04-12  7:28           ` [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- FIXED! Russell King
2004-04-12  9:08             ` David Hinds
2004-04-12  9:27               ` Russell King
2004-04-12 14:40             ` Ivica Ico Bukvic
2004-04-12 14:40               ` Ivica Ico Bukvic
2004-04-12 14:53               ` Russell King
2004-04-12 15:31                 ` Daniel Ritz
2004-04-12 15:38                   ` Russell King
2004-04-12 18:03                     ` Daniel Ritz
2004-04-14 13:41                     ` Tim Blechmann
2004-04-12 22:06               ` Tim Blechmann
2004-04-12 22:06                 ` Tim Blechmann
2004-04-12 11:02           ` Tim Blechmann
2004-04-12 11:02             ` Tim Blechmann
2004-04-12 10:39             ` Russell King
2004-04-12 12:09               ` Tim Blechmann
2004-04-12 15:19           ` Daniel Ritz
2004-04-12 15:19             ` Daniel Ritz

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.