sb16 gets wedged when doing overlapped i/o (full duplex)

sb16 gets wedged when doing overlapped i/o (full duplex)

[John S. Denker]

	==== This is a slightly-updated clone of item
	#648232 on the sourceforge bug/patch reporting
	system.  I'm moving it to here (the alsa-devel
	mailing list) at the request of Jaroslav. ====

Things run OK for a few minutes (sometimes 30 seconds,
sometimes 5+ minutes) then ALSA gets wedged.  Every read or
write results in an error.  This only happens when I'm doing
overlapped i/o; pure input runs happily for hours, and
although I haven't tried it I assume pure output works fine.

I observe this on two different machines using two different
models of card (classic sb16 PnP and sb32awe).

This is clearly a driver problem, not a problem in my
program, because when the ALSA system gets wedged, it stays
wedged.  If I kill and restart the program while things are
wedged, it puts out what sounds like one buffer of audio and
then gets nothing but errors.  There is a ten-second pause
associated with each error.  Then, if I do init.d/alsactl
restart, i.e. unload and reload the modules, we are back
where we started: things will run fine for a few minutes.

I'm doing stereo * 44100 frames per second * two
directions. The same pattern of i/o on a different machine
(faster cpu) with a different driver (snd-intel8x0) works
fine.

I observe the same problems with rc6 and also with
9.0beta11, so the problem has been lurking there for quite a
while.

The message (under rc6) is:
ALSA lib pcm_hw.c:428:(snd_pcm_hw_prepare)
SNDRV_PCM_IOCTL_PREPARE failed: Device or resource busy

The message is the same for beta11, except line 349.

Once it gets wedged, writes and reads both fail, with the
same message.

Because the runtime before failure is far from constant, I
suspect some sort of race condition. I tried varying the
load on the machine. I intermittently imposed enough load to
cause the application to suffer underruns, but this had no
discernible effect on the incidence of the wedge problem.

Further experiments tend to suggest that lowering the
frame-rate from 44100 to 22050 decreases the incidence of
the wedge problem by roughly a factor of two.  I suspect
most people don't do overlapped i/o at 44100 fps, which may
explain why the bug hasn't been reported before.

References, possibly related, possibly not:
http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg02194.html
http://www.mail-archive.com/alsa-devel@lists.sourceforge.net/msg05183.html
http://www.mail-archive.com/alsa-devel@lists.sourceforge.net/msg05195.html



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

usbaudio won't do 24-bit or 32-bit i/o, and won't do 96000 frames per second

[John S. Denker]

     ==== This is a slightly-updated clone of item
     #636946 on the sourceforge bug/patch reporting
     system.  I'm moving it to here (the alsa-devel
     mailing list) at the request of Jaroslav. ====

I bought an Extigy, which is capable of 24-bit i/o. It is
also capable of digitizing 96000 frames per second.

The problem is, the alsa usbaudio driver seems to know
nothing of such capabilities.

I tried modifying the driver source, in analogy to the dummy
driver, but to no avail.

This means I am unable to use ALSA for this application.

Request #1: USB driver supporting 24-bit i/o. I don't care
whether it is encoded as S24_LE or S32_LE, just so long as
all the bits are encoded somehow.

Request #2: USB driver supporting 96000 frames per second.

Suggestion: If the code had better comments and
documentation, it would be easier for folks like me to
contribute fixes to problems such as this.

Note: there are other problems with this driver; see next
bug report.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: usbaudio won't do 24-bit or 32-bit i/o, and won't do 96000 frames per second

[Clemens Ladisch]

John S. Denker wrote:
> Request #1: USB driver supporting 24-bit i/o.
> Request #2: USB driver supporting 96000 frames per second.

What you want is already supported by the snd-usb-audio driver. IIRC
Patrick Shirkey reported that 24bit@96kHz works with the M-Audio Quattro.

> I bought an Extigy, which is capable of 24-bit i/o. It is
> also capable of digitizing 96000 frames per second.
>
> The problem is, the alsa usbaudio driver seems to know
> nothing of such capabilities.

USB devices announce their capabilities in their descriptors. Please post
the output of lsusb and the output of "od -t x1 /proc/bus/usb/001/xxx"
(xxx is the device number; try all files there, the one I want to see has
"1E 04" somewhere in the first line).


HTH
Clemens



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: usbaudio won't do 24-bit or 32-bit i/o, and won't do 96000 frames per second

[John S. Denker]

[-- Attachment #1: Type: text/plain, Size: 596 bytes --]

Clemens Ladisch wrote:

> USB devices announce their capabilities in their descriptors. Please
> post the output of lsusb and the output of "od -t x1
> /proc/bus/usb/001/xxx" (xxx is the device number; try all files
> there, the one I want to see has "1E 04" somewhere in the first
> line).

As requested:

1)    lsusb
Unknown line at line 1809
Duplicate HUT Usage Spec at line 2650
Bus 001 Device 001: ID 0000:0000 Virtual Hub
Bus 001 Device 003: ID 041e:3000 Creative Labs

2) The od is attached as a .txt file.

3) Perhaps easier to use is the output of usbview,
also attached as a .txt file.

[-- Attachment #2: extigy-od.txt --]
[-- Type: text/plain, Size: 2852 bytes --]

0000000 12 01 10 01 00 00 00 40 1e 04 00 30 00 01 01 02
0000020 00 01 09 02 1a 03 04 01 00 c0 00 09 04 00 00 01
0000040 01 01 00 00 0b 24 01 00 01 9a 01 03 01 02 03 0c
0000060 24 02 01 01 01 00 06 3f 00 00 00 15 24 06 02 01
0000100 02 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000120 0c 24 02 03 01 01 00 06 3f 00 00 00 0c 24 02 04
0000140 02 06 00 06 3f 00 00 00 08 24 05 05 02 03 04 00
0000160 15 24 06 06 05 02 03 00 00 00 00 00 00 00 00 00
0000200 00 00 00 00 00 0c 24 02 07 03 06 00 02 03 00 00
0000220 00 0d 24 06 08 07 02 03 00 02 00 02 00 00 0c 24
0000240 02 09 01 02 00 02 03 00 00 00 0d 24 06 0a 09 02
0000260 03 00 00 00 00 00 00 09 24 05 0b 03 07 09 11 00
0000300 0d 24 06 0c 0b 02 03 00 00 00 00 00 00 09 24 03
0000320 0d 01 01 00 0c 00 11 24 04 0e 02 08 06 02 03 00
0000340 00 00 00 00 00 00 00 0f 24 07 0f 03 00 01 0e 05
0000360 37 00 00 01 01 00 1a 24 04 10 04 02 06 0f 0a 06
0000400 3f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000420 1e 24 07 11 01 00 01 10 06 3f 00 00 01 03 00 07
0000440 03 00 03 00 0b 00 33 00 3b 00 37 00 3f 00 15 24
0000460 06 12 11 02 17 00 02 00 02 00 02 00 02 00 02 00
0000500 02 00 00 0f 24 08 1b 00 00 01 12 06 3f 00 00 01
0000520 01 00 0e 24 06 1c 1b 01 01 00 00 00 00 00 00 00
0000540 09 24 03 13 01 03 00 1c 00 09 24 03 14 02 03 00
0000560 12 00 0f 24 08 15 00 00 01 1b 06 3f 00 00 01 01
0000600 00 0e 24 06 16 15 01 01 00 00 00 00 00 00 00 0e
0000620 24 06 17 16 01 01 00 00 00 00 00 00 00 09 24 03
0000640 18 02 06 00 17 00 0e 24 06 19 16 01 01 00 00 00
0000660 00 00 00 00 09 24 03 1a 02 06 00 19 00 07 05 81
0000700 03 08 00 0a 09 04 01 00 00 01 02 00 00 09 04 01
0000720 01 02 01 02 00 00 07 24 01 01 00 01 00 0b 24 02
0000740 01 02 02 10 01 80 bb 00 09 05 02 05 c8 00 01 00
0000760 03 07 25 01 00 00 00 00 09 05 83 01 03 00 01 06
0001000 00 09 04 02 00 00 01 02 00 00 09 04 02 01 01 01
0001020 02 00 00 07 24 01 0d 00 01 00 0b 24 02 01 02 02
0001040 10 01 40 1f 00 09 05 86 05 28 00 01 00 00 07 25
0001060 01 00 00 00 00 09 04 02 02 01 01 02 00 00 07 24
0001100 01 0d 00 01 00 0b 24 02 01 02 02 10 01 80 3e 00
0001120 09 05 86 05 48 00 01 00 00 07 25 01 00 00 00 00
0001140 09 04 02 03 01 01 02 00 00 07 24 01 0d 00 01 00
0001160 0b 24 02 01 02 02 10 01 c0 5d 00 09 05 86 05 68
0001200 00 01 00 00 07 25 01 00 00 00 00 09 04 02 04 01
0001220 01 02 00 00 07 24 01 0d 00 01 00 0b 24 02 01 02
0001240 02 10 01 00 7d 00 09 05 86 05 88 00 01 00 00 07
0001260 25 01 00 00 00 00 09 04 02 05 01 01 02 00 00 07
0001300 24 01 0d 00 01 00 0b 24 02 01 02 02 10 01 80 bb
0001320 00 09 05 86 05 c8 00 01 00 00 07 25 01 00 00 00
0001340 00 09 04 03 00 00 01 02 00 00 09 04 03 01 02 01
0001360 02 00 00 07 24 01 03 00 02 10 0f 24 02 02 80 02
0001400 00 06 02 44 ac 00 80 bb 00 0a 24 03 02 10 1f 00
0001420 00 00 00 09 05 04 05 54 00 01 00 05 07 25 01 00
0001440 00 00 00 09 05 85 01 03 00 01 06 00
0001454

[-- Attachment #3: usbview.txt --]
[-- Type: text/plain, Size: 3048 bytes --]

Sound Blaster Extigy
Manufacturer: Creative Technology Ltd.
Speed: 12Mb/s (full)
USB Version:  1.10
Device Class: 00(>ifc )
Device Subclass: 00
Device Protocol: 00
Maximum Default Endpoint Size: 64
Number of Configurations: 1
Vendor Id: 041e
Product Id: 3000
Revision Number:  1.00

Config Number: 1
	Number of Interfaces: 4
	Attributes: c0
	MaxPower Needed:   0mA

	Interface Number: 0
		Name: snd-usb-audio
		Alternate Number: 0
		Class: 01(audio) 
		Sub Class: 1
		Protocol: 0
		Number of Endpoints: 1

			Endpoint Address: 81
			Direction: in
			Attribute: 3
			Type: Int.
			Max Packet Size: 8
			Interval:  10ms

	Interface Number: 1
		Name: snd-usb-audio
		Alternate Number: 0
		Class: 01(audio) 
		Sub Class: 2
		Protocol: 0
		Number of Endpoints: 0

	Interface Number: 1
		Name: snd-usb-audio
		Alternate Number: 1
		Class: 01(audio) 
		Sub Class: 2
		Protocol: 0
		Number of Endpoints: 2

			Endpoint Address: 02
			Direction: out
			Attribute: 5
			Type: Isoc
			Max Packet Size: 200
			Interval:   1ms

			Endpoint Address: 83
			Direction: in
			Attribute: 1
			Type: Isoc
			Max Packet Size: 3
			Interval:   1ms

	Interface Number: 2
		Name: snd-usb-audio
		Alternate Number: 0
		Class: 01(audio) 
		Sub Class: 2
		Protocol: 0
		Number of Endpoints: 0

	Interface Number: 2
		Name: snd-usb-audio
		Alternate Number: 1
		Class: 01(audio) 
		Sub Class: 2
		Protocol: 0
		Number of Endpoints: 1

			Endpoint Address: 86
			Direction: in
			Attribute: 5
			Type: Isoc
			Max Packet Size: 40
			Interval:   1ms

	Interface Number: 2
		Name: snd-usb-audio
		Alternate Number: 2
		Class: 01(audio) 
		Sub Class: 2
		Protocol: 0
		Number of Endpoints: 1

			Endpoint Address: 86
			Direction: in
			Attribute: 5
			Type: Isoc
			Max Packet Size: 72
			Interval:   1ms

	Interface Number: 2
		Name: snd-usb-audio
		Alternate Number: 3
		Class: 01(audio) 
		Sub Class: 2
		Protocol: 0
		Number of Endpoints: 1

			Endpoint Address: 86
			Direction: in
			Attribute: 5
			Type: Isoc
			Max Packet Size: 104
			Interval:   1ms

	Interface Number: 2
		Name: snd-usb-audio
		Alternate Number: 4
		Class: 01(audio) 
		Sub Class: 2
		Protocol: 0
		Number of Endpoints: 1

			Endpoint Address: 86
			Direction: in
			Attribute: 5
			Type: Isoc
			Max Packet Size: 136
			Interval:   1ms

	Interface Number: 2
		Name: snd-usb-audio
		Alternate Number: 5
		Class: 01(audio) 
		Sub Class: 2
		Protocol: 0
		Number of Endpoints: 1

			Endpoint Address: 86
			Direction: in
			Attribute: 5
			Type: Isoc
			Max Packet Size: 200
			Interval:   1ms

	Interface Number: 3
		Name: snd-usb-audio
		Alternate Number: 0
		Class: 01(audio) 
		Sub Class: 2
		Protocol: 0
		Number of Endpoints: 0

	Interface Number: 3
		Name: snd-usb-audio
		Alternate Number: 1
		Class: 01(audio) 
		Sub Class: 2
		Protocol: 0
		Number of Endpoints: 2

			Endpoint Address: 04
			Direction: out
			Attribute: 5
			Type: Isoc
			Max Packet Size: 84
			Interval:   1ms

			Endpoint Address: 85
			Direction: in
			Attribute: 1
			Type: Isoc
			Max Packet Size: 3
			Interval:   1ms

Re: usbaudio won't do 24-bit or 32-bit i/o, and won't do 96000 frames per second

[Clemens Ladisch]

John S. Denker wrote:
> As requested:
>
> 1)    lsusb
> Unknown line at line 1809
> Duplicate HUT Usage Spec at line 2650
> Bus 001 Device 001: ID 0000:0000 Virtual Hub
> Bus 001 Device 003: ID 041e:3000 Creative Labs

Oops. I forgot to tell you to use "lsusb -vv". But don't bother, the od
output suffices for now.

> 2) The od is attached as a .txt file.

The descriptors announce the following capabilities:

interface 0: various (mixer) controls
interface 1: output 16 bits at 48 kHz, 2 channels
interface 2: input 16 bits at 8/16/24/32/48 kHz, 2 channels
interface 3: output AC-3 at 44.1/48 kHz

... and that's it.

Now when I look at the specifications at
<http://www.soundblaster.com/products/extigy/specs.asp> it turns out that
Creative isn't outright lying, only being _extremely_ misleading: the page
says that the ADC and DAC are capable of converting 24 bit data at 96kHz,
but it does _not_ say that this bit depth and/or samping rate can be used
to playback or record data from/to the computer. (It says the SPDIF input
can do 24@96, but that's of no use if this format cannot be sent over the
USB bus.)

6-channel output is supported with AC-3 only, but the driver currently
doesn't support AC-3.


To summarize: Where it matters, the Extigy does neither 24 bits nor 96kHz.
For professional audio, you have to go elsewhere.


Best regards,
Clemens



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: usbaudio won't do 24-bit or 32-bit i/o, and won't do 96000 frames per second

[Jaroslav Kysela]

On Fri, 6 Dec 2002, Clemens Ladisch wrote:

> John S. Denker wrote:
> > As requested:
> >
> > 1)    lsusb
> > Unknown line at line 1809
> > Duplicate HUT Usage Spec at line 2650
> > Bus 001 Device 001: ID 0000:0000 Virtual Hub
> > Bus 001 Device 003: ID 041e:3000 Creative Labs
> 
> Oops. I forgot to tell you to use "lsusb -vv". But don't bother, the od
> output suffices for now.
> 
> > 2) The od is attached as a .txt file.
> 
> The descriptors announce the following capabilities:
> 
> interface 0: various (mixer) controls
> interface 1: output 16 bits at 48 kHz, 2 channels
> interface 2: input 16 bits at 8/16/24/32/48 kHz, 2 channels
> interface 3: output AC-3 at 44.1/48 kHz
> 
> ... and that's it.
> 
> Now when I look at the specifications at
> <http://www.soundblaster.com/products/extigy/specs.asp> it turns out that
> Creative isn't outright lying, only being _extremely_ misleading: the page
> says that the ADC and DAC are capable of converting 24 bit data at 96kHz,
> but it does _not_ say that this bit depth and/or samping rate can be used
> to playback or record data from/to the computer. (It says the SPDIF input
> can do 24@96, but that's of no use if this format cannot be sent over the
> USB bus.)
> 
> 6-channel output is supported with AC-3 only, but the driver currently
> doesn't support AC-3.
> 
> 
> To summarize: Where it matters, the Extigy does neither 24 bits nor 96kHz.
> For professional audio, you have to go elsewhere.

Another big joke from the Creative PR staff ;-((
Patrick, could you add this info to USB device web pages?

						Jaroslav

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




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: usbaudio won't do 24-bit or 32-bit i/o, and won't do 96000 frames per second

[Patrick Shirkey]

Jaroslav Kysela wrote:

> 
> Another big joke from the Creative PR staff ;-((
> Patrick, could you add this info to USB device web pages?
> 

Done.

-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: usbaudio won't do 24-bit or 32-bit i/o, and won't do 96000 frames per second

[John S. Denker]

Clemens Ladisch wrote:

> Now when I look at the specifications at it turns out that
> Creative isn't outright lying, only being _extremely_ misleading

Whaaat??  Hype and deception from Creative Labs???

Apparently that only happens on days when the sun
rises in the east and sets in the west.

 > To summarize: Where it matters, the Extigy does neither
 > 24 bits nor 96kHz.  For professional audio, you have to
 > go elsewhere.

Thanks for sorting this out.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

many utils fail for extigy (usb)

[John S. Denker]

[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]

  ; alsactl -f /tmp/foo.ctl store
alsactl: get_control:202: Cannot read control '2,0,0,Digital In Playback 
Source,0': Invalid argument
alsactl: get_control:202: Cannot read control '2,0,0,3D Stereo Extender 
Switch,0': Invalid argument
alsactl: get_control:202: Cannot read control '2,0,0,Up Down Switch,0': 
Invalid argument
alsactl: get_control:202: Cannot read control '2,0,0,Up Down Mode 
Select,0': Invalid argument

The resulting alsactl file is attached.

Note that I have hacked alsactl to make such errors
non-fatal;  otherwise it would have died after the
first message.

Also, in the following, note the bizarre numbers (values
of the 'index' variable)

  ; alsactl -f /tmp/foo.ctl restore
alsactl: set_control:976: Cannot write control '2:0:0:Digital In 
Playback Source:134521100' : Invalid argument
alsactl: set_control:976: Cannot write control '2:0:0:3D Stereo Extender 
Switch:134521100' : Invalid argument
alsactl: set_control:976: Cannot write control '2:0:0:Up Down 
Switch:134521100' : Invalid argument
alsactl: set_control:976: Cannot write control '2:0:0:Up Down Mode 
Select:134521100' : Invalid argument

  ; amixer
amixer: Mixer load error: default

  ; alsamixer
alsamixer: function snd_mixer_load failed: Invalid argument

[-- Attachment #2: foo-ctl.txt --]
[-- Type: text/plain, Size: 8734 bytes --]

state.82801BAICH2 {
	control.1 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'Master Playback Switch'
		value false
	}
	control.2 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 63'
		iface MIXER
		name 'Master Playback Volume'
		value.0 0
		value.1 0
	}
	control.3 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'Headphone Playback Switch'
		value false
	}
	control.4 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 63'
		iface MIXER
		name 'Headphone Playback Volume'
		value.0 0
		value.1 0
	}
	control.5 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'Master Mono Playback Switch'
		value false
	}
	control.6 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 31'
		iface MIXER
		name 'Master Mono Playback Volume'
		value 0
	}
	control.7 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'PC Speaker Playback Switch'
		value false
	}
	control.8 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 15'
		iface MIXER
		name 'PC Speaker Playback Volume'
		value 0
	}
	control.9 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'Phone Playback Switch'
		value false
	}
	control.10 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 31'
		iface MIXER
		name 'Phone Playback Volume'
		value 0
	}
	control.11 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'Mic Playback Switch'
		value false
	}
	control.12 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 31'
		iface MIXER
		name 'Mic Playback Volume'
		value 0
	}
	control.13 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'Mic Boost (+20dB)'
		value false
	}
	control.14 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'Line Playback Switch'
		value false
	}
	control.15 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 31'
		iface MIXER
		name 'Line Playback Volume'
		value.0 0
		value.1 0
	}
	control.16 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'CD Playback Switch'
		value false
	}
	control.17 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 31'
		iface MIXER
		name 'CD Playback Volume'
		value.0 0
		value.1 0
	}
	control.18 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'Video Playback Switch'
		value false
	}
	control.19 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 31'
		iface MIXER
		name 'Video Playback Volume'
		value.0 0
		value.1 0
	}
	control.20 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'Aux Playback Switch'
		value false
	}
	control.21 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 31'
		iface MIXER
		name 'Aux Playback Volume'
		value.0 0
		value.1 0
	}
	control.22 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'PCM Playback Switch'
		value false
	}
	control.23 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 31'
		iface MIXER
		name 'PCM Playback Volume'
		value.0 0
		value.1 0
	}
	control.24 {
		comment.access 'read write'
		comment.type ENUMERATED
		comment.item.0 Mic
		comment.item.1 CD
		comment.item.2 Video
		comment.item.3 Aux
		comment.item.4 Line
		comment.item.5 Mix
		comment.item.6 'Mix Mono'
		comment.item.7 Phone
		iface MIXER
		name 'Capture Source'
		value.0 Mic
		value.1 Mic
	}
	control.25 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'Capture Switch'
		value true
	}
	control.26 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 15'
		iface MIXER
		name 'Capture Volume'
		value.0 0
		value.1 0
	}
	control.27 {
		comment.access 'read write'
		comment.type ENUMERATED
		comment.item.0 'pre 3D'
		comment.item.1 'post 3D'
		iface MIXER
		name 'PCM Out Path & Mute'
		value 'pre 3D'
	}
	control.28 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name '3D Control - Switch'
		value false
	}
	control.29 {
		comment.access 'read write'
		comment.type ENUMERATED
		comment.item.0 Mix
		comment.item.1 Mic
		iface MIXER
		name 'Mono Output Select'
		value Mix
	}
	control.30 {
		comment.access 'read write'
		comment.type ENUMERATED
		comment.item.0 Mic1
		comment.item.1 Mic2
		iface MIXER
		name 'Mic Select'
		value Mic1
	}
	control.31 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 15'
		iface MIXER
		name '3D Control - Center'
		value 0
	}
	control.32 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 15'
		iface MIXER
		name '3D Control - Depth'
		value 0
	}
	control.33 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'External Amplifier Power Down'
		value false
	}
}
state.Extigy {
	control.1 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'PCM Playback Switch'
		value true
	}
	control.2 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 25600'
		iface MIXER
		name 'PCM Playback Volume'
		value 25600
	}
	control.3 {
		comment.access 'read write'
		comment.type ENUMERATED
		comment.item.0 PCM
		comment.item.1 'Input 1'
		iface MIXER
		name 'Digital In Playback Source'
		value PCM
	}
	control.4 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'Digital In Switch'
		value true
	}
	control.5 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 25600'
		iface MIXER
		name 'Digital In Volume'
		value 25600
	}
	control.6 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'Line Playback Switch'
		value false
	}
	control.7 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 25600'
		iface MIXER
		name 'Line Playback Volume'
		value.0 22528
		value.1 22528
	}
	control.8 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 25600'
		iface MIXER
		name 'Line Playback Volume'
		index 1
		value 22528
	}
	control.9 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name '3D Stereo Extender Switch'
		value false
	}
	control.10 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'Mic Playback Switch'
		value false
	}
	control.11 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 25600'
		iface MIXER
		name 'Mic Playback Volume'
		value 25600
	}
	control.12 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'Up Down Switch'
		value false
	}
	control.13 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 1'
		iface MIXER
		name 'Up Down Mode Select'
		value 0
	}
	control.14 {
		comment.access 'read write'
		comment.type ENUMERATED
		comment.item.0 'Input 0'
		comment.item.1 Mic
		comment.item.2 Mixer
		iface MIXER
		name 'Capture Source'
		value 'Input 0'
	}
	control.15 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'Capture Switch'
		value true
	}
	control.16 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 25600'
		iface MIXER
		name 'Capture Volume'
		value 25600
	}
	control.17 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'Master Playback Switch'
		value true
	}
	control.18 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 25600'
		iface MIXER
		name 'Master Playback Volume'
		value.0 19456
		value.1 19456
		value.2 19456
		value.3 19456
		value.4 19456
		value.5 19456
	}
	control.19 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 25600'
		iface MIXER
		name 'Master Playback Volume'
		index 1
		value 19456
	}
	control.20 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 96'
		iface MIXER
		name 'Tone Control - Bass'
		value 48
	}
	control.21 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 96'
		iface MIXER
		name 'Tone Control - Treble'
		value 48
	}
	control.22 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'Speaker Playback Switch'
		value true
	}
	control.23 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'Digital Out Playback Switch'
		value true
	}
	control.24 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'Digital Out1 Playback Switch'
		value true
	}
	control.25 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'Digital Out2 Playback Switch'
		value true
	}
}

Re: usbaudio won't do 24-bit or 32-bit i/o, and won't do 96000 frames per second

[Patrick Shirkey]

Clemens Ladisch wrote:
> John S. Denker wrote:
> 
>>Request #1: USB driver supporting 24-bit i/o.
>>Request #2: USB driver supporting 96000 frames per second.
> 
> 
> What you want is already supported by the snd-usb-audio driver. IIRC
> Patrick Shirkey reported that 24bit@96kHz works with the M-Audio Quattro.
> 

Actually I have just yesterday noticed a specific problem with the 24 
bit support.

Also you should know that the quattro only supports 24_3le which is 24 
bits, three bytes. This is contrary to possibly all other pro devices 
which support 24bits, four bytes or something like that. Meaning that 
you have to use a special bit depth just for the quattro. This could be 
the problem you are seeing.

Currently I am using the cvs from the 18 November. I will update and 
check again. I have initialised both pcms and I cannot record a signal 
through the first pcm hw:1,0 although arecord doesn't complain.

Using 24_3le,2,44100 I get a normal signal on the left (input 3) but 
maxed signal on the right (input 4). If I press in the input level 
button on the device input 3 is boosted (again normal operation) but 
input 4 is still maxed.

I have verified it is the same for 88200 and 96000hz too.

arecord will not work for 88200 or 96000 at 16 bit eg.

arecord -D hw:1,1 -c 2 -f s16_le -r 88200 -d 10 
/art/1music/rec/test-10sec-88-16.wav
Recording WAVE '/art/1music/rec/test-10sec-88-16.wav' : Signed 16 bit 
Little Endian, Rate 88200 Hz, Stereo
ALSA lib pcm_hw.c:428:(snd_pcm_hw_prepare) SNDRV_PCM_IOCTL_PREPARE 
failed: Invalid argument
arecord: set_params:814: Unable to install hw params:
ACCESS:  RW_INTERLEAVED
FORMAT:  S16_LE
SUBFORMAT:  STD
SAMPLE_BITS: 16
FRAME_BITS: 32
CHANNELS: 2
RATE: 88200
PERIOD_TIME: (46439 46440)
PERIOD_SIZE: 4096
PERIOD_BYTES: 16384
PERIODS: 4
BUFFER_TIME: (185759 185760)
BUFFER_SIZE: 16384
BUFFER_BYTES: 65536
TICK_TIME: 10000




-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No! 
We want normal music!", I think that was more like acting than anything 
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: usbaudio won't do 24-bit or 32-bit i/o, and won't do 96000 frames per second

[Patrick Shirkey]

Patrick Shirkey wrote:

> Currently I am using the cvs from the 18 November. I will update and 
> check again. 
> 

It is the same with the latest cvs.

-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No! 
We want normal music!", I think that was more like acting than anything 
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: usbaudio won't do 24-bit or 32-bit i/o, and won't do 96000 frames per second

[Takashi Iwai]

Hi Patrick,

At Fri, 06 Dec 2002 15:48:14 +0900,
Patrick Shirkey wrote:
> 
> Clemens Ladisch wrote:
> > John S. Denker wrote:
> > 
> >>Request #1: USB driver supporting 24-bit i/o.
> >>Request #2: USB driver supporting 96000 frames per second.
> > 
> > 
> > What you want is already supported by the snd-usb-audio driver. IIRC
> > Patrick Shirkey reported that 24bit@96kHz works with the M-Audio Quattro.
> > 
> 
> Actually I have just yesterday noticed a specific problem with the 24 
> bit support.
> 
> Also you should know that the quattro only supports 24_3le which is 24 
> bits, three bytes. This is contrary to possibly all other pro devices 
> which support 24bits, four bytes or something like that. Meaning that 
> you have to use a special bit depth just for the quattro. This could be 
> the problem you are seeing.
> 
> Currently I am using the cvs from the 18 November. I will update and 
> check again. I have initialised both pcms and I cannot record a signal 
> through the first pcm hw:1,0 although arecord doesn't complain.

could you tell me the rcs version numbers of the files on
alsa-kernel/usb you are using (18 Nov.) ?  i've checked the files via
cvs but i couldn't see any differences around the date.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: usbaudio won't do 24-bit or 32-bit i/o...

[Patrick Shirkey]

Takashi Iwai wrote:

> 
> could you tell me the rcs version numbers of the files on
> alsa-kernel/usb you are using (18 Nov.) ?  i've checked the files via
> cvs but i couldn't see any differences around the date.
> 

I have managed to test a more upto date version since then and it is the 
same. I have no idea when this happened though as I wasn't actively 
testing the 24 bit support until recently. I have a vague memory of 
testing it much earlier in the year but I think that was only for playback.

I currently cannot record from input 1 and 2 either.

Working are:

output 1,2,3,4
input 3,4

I also have to initialise both pcms with the small utility you made.




-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No! 
We want normal music!", I think that was more like acting than anything 
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: usbaudio won't do 24-bit or 32-bit i/o...

[Takashi Iwai]

[-- Attachment #1: Type: text/plain, Size: 1052 bytes --]

At Sat, 14 Dec 2002 19:48:25 +0900,
Patrick Shirkey wrote:
> 
> Takashi Iwai wrote:
> 
> > 
> > could you tell me the rcs version numbers of the files on
> > alsa-kernel/usb you are using (18 Nov.) ?  i've checked the files via
> > cvs but i couldn't see any differences around the date.
> > 
> 
> I have managed to test a more upto date version since then and it is the 
> same. I have no idea when this happened though as I wasn't actively 
> testing the 24 bit support until recently. I have a vague memory of 
> testing it much earlier in the year but I think that was only for playback.
> 
> I currently cannot record from input 1 and 2 either.
 
hmm, it's weird.  it would be nice if we can know at which point the
driver became broken...


> Working are:
> 
> output 1,2,3,4
> input 3,4
> 
> I also have to initialise both pcms with the small utility you made.

the attached patch will (hopefully) do the same thing as qinit in the
kernel at the initialization (applied to the latest cvs).  please let
me know whether it works.


ciao,

Takashi

[-- Attachment #2: usb-qinit.dif --]
[-- Type: application/octet-stream, Size: 5522 bytes --]

Index: alsa-kernel/usb/usbaudio.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/usb/usbaudio.c,v
retrieving revision 1.29
diff -u -r1.29 usbaudio.c
--- alsa-kernel/usb/usbaudio.c	16 Dec 2002 17:15:05 -0000	1.29
+++ alsa-kernel/usb/usbaudio.c	16 Dec 2002 17:14:16 -0000
@@ -928,6 +928,70 @@
 
 
 /*
+ * initialize the picth control and sample rate
+ */
+static int init_usb_pitch(struct usb_device *dev, int iface,
+			  struct usb_host_interface *alts,
+			  struct audioformat *fmt)
+{
+	unsigned int ep;
+	unsigned char data[1];
+	int err;
+
+	ep = get_endpoint(alts, 0)->bEndpointAddress;
+	/* if endpoint has pitch control, enable it */
+	if (fmt->attributes & EP_CS_ATTR_PITCH_CONTROL) {
+		data[0] = 1;
+		if ((err = usb_control_msg(dev, usb_sndctrlpipe(dev, 0), SET_CUR,
+					   USB_TYPE_CLASS|USB_RECIP_ENDPOINT|USB_DIR_OUT, 
+					   PITCH_CONTROL << 8, ep, data, 1, HZ)) < 0) {
+			snd_printk(KERN_ERR "%d:%d:%d: cannot set enable PITCH\n",
+				   dev->devnum, iface, ep);
+			return err;
+		}
+	}
+	return 0;
+}
+
+static int init_usb_sample_rate(struct usb_device *dev, int iface,
+				struct usb_host_interface *alts,
+				struct audioformat *fmt, int rate)
+{
+	unsigned int ep;
+	unsigned char data[3];
+	int err;
+
+	ep = get_endpoint(alts, 0)->bEndpointAddress;
+	/* if endpoint has sampling rate control, set it */
+	if (fmt->attributes & EP_CS_ATTR_SAMPLE_RATE) {
+		int crate;
+		data[0] = rate;
+		data[1] = rate >> 8;
+		data[2] = rate >> 16;
+		if ((err = usb_control_msg(dev, usb_sndctrlpipe(dev, 0), SET_CUR,
+					   USB_TYPE_CLASS|USB_RECIP_ENDPOINT|USB_DIR_OUT, 
+					   SAMPLING_FREQ_CONTROL << 8, ep, data, 3, HZ)) < 0) {
+			snd_printk(KERN_ERR "%d:%d:%d: cannot set freq %d to ep 0x%x\n",
+				   dev->devnum, iface, fmt->altsetting, rate, ep);
+			return err;
+		}
+		if ((err = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0), GET_CUR,
+					   USB_TYPE_CLASS|USB_RECIP_ENDPOINT|USB_DIR_IN,
+					   SAMPLING_FREQ_CONTROL << 8, ep, data, 3, HZ)) < 0) {
+			snd_printk(KERN_ERR "%d:%d:%d: cannot get freq at ep 0x%x\n",
+				   dev->devnum, iface, fmt->altsetting, ep);
+			return err;
+		}
+		crate = data[0] | (data[1] << 8) | (data[2] << 16);
+		if (crate != rate) {
+			snd_printd(KERN_WARNING "current rate %d is different from the runtime rate %d\n", crate, rate);
+			// runtime->rate = crate;
+		}
+	}
+	return 0;
+}
+
+/*
  * find a matching format and set up the interface
  */
 static int set_format(snd_usb_substream_t *subs, snd_pcm_runtime_t *runtime)
@@ -939,7 +1003,6 @@
 	struct usb_interface *iface;
 	struct audioformat *fmt;
 	unsigned int ep, attr;
-	unsigned char data[3];
 	int is_playback = subs->direction == SNDRV_PCM_STREAM_PLAYBACK;
 	int err;
 
@@ -1012,44 +1075,11 @@
 		subs->syncinterval = get_endpoint(alts, 1)->bRefresh;
 	}
 
-	ep = get_endpoint(alts, 0)->bEndpointAddress;
-	/* if endpoint has pitch control, enable it */
-	if (fmt->attributes & EP_CS_ATTR_PITCH_CONTROL) {
-		data[0] = 1;
-		if ((err = usb_control_msg(dev, usb_sndctrlpipe(dev, 0), SET_CUR,
-					   USB_TYPE_CLASS|USB_RECIP_ENDPOINT|USB_DIR_OUT, 
-					   PITCH_CONTROL << 8, ep, data, 1, HZ)) < 0) {
-			snd_printk(KERN_ERR "%d:%d:%d: cannot set enable PITCH\n",
-				   dev->devnum, subs->interface, ep);
-			return err;
-		}
-	}
-	/* if endpoint has sampling rate control, set it */
-	if (fmt->attributes & EP_CS_ATTR_SAMPLE_RATE) {
-		int crate;
-		data[0] = runtime->rate;
-		data[1] = runtime->rate >> 8;
-		data[2] = runtime->rate >> 16;
-		if ((err = usb_control_msg(dev, usb_sndctrlpipe(dev, 0), SET_CUR,
-					   USB_TYPE_CLASS|USB_RECIP_ENDPOINT|USB_DIR_OUT, 
-					   SAMPLING_FREQ_CONTROL << 8, ep, data, 3, HZ)) < 0) {
-			snd_printk(KERN_ERR "%d:%d:%d: cannot set freq %d to ep 0x%x\n",
-				   dev->devnum, subs->interface, fmt->altsetting, runtime->rate, ep);
-			return err;
-		}
-		if ((err = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0), GET_CUR,
-					   USB_TYPE_CLASS|USB_RECIP_ENDPOINT|USB_DIR_IN,
-					   SAMPLING_FREQ_CONTROL << 8, ep, data, 3, HZ)) < 0) {
-			snd_printk(KERN_ERR "%d:%d:%d: cannot get freq at ep 0x%x\n",
-				   dev->devnum, subs->interface, fmt->altsetting, ep);
-			return err;
-		}
-		crate = data[0] | (data[1] << 8) | (data[2] << 16);
-		if (crate != runtime->rate) {
-			snd_printd(KERN_WARNING "current rate %d is different from the runtime rate %d\n", crate, runtime->rate);
-			// runtime->rate = crate;
-		}
-	}
+	if ((err = init_usb_pitch(dev, subs->interface, alts, fmt)) < 0 ||
+	    (err = init_usb_sample_rate(dev, subs->interface, alts, fmt,
+					runtime->rate)) < 0)
+		return err;
+
 	/* always fill max packet size */
 	if (fmt->attributes & EP_CS_ATTR_FILL_MAX)
 		subs->fill_max = 1;
@@ -1829,6 +1859,10 @@
 			kfree(fp);
 			return err;
 		}
+		/* try to set the interface... */
+		usb_set_interface(chip->dev, iface_no, i);
+		init_usb_pitch(chip->dev, iface_no, alts, fp);
+		init_usb_sample_rate(chip->dev, iface_no, alts, fp, fp->rate_max);
 	}
 	return 0;
 }
@@ -1891,9 +1925,10 @@
 			/* skip non-supported classes */
 			continue;
 		}
-		parse_audio_endpoints(chip, buffer, buflen, j);
-		usb_set_interface(dev, j, 0); /* reset the current interface */
-		usb_driver_claim_interface(&usb_audio_driver, iface, (void *)-1);
+		if (! parse_audio_endpoints(chip, buffer, buflen, j)) {
+			usb_set_interface(dev, j, 0); /* reset the current interface */
+			usb_driver_claim_interface(&usb_audio_driver, iface, (void *)-1);
+		}
 	}
 
 	return 0;

Re: usbaudio won't do 24-bit or 32-bit i/o...

[Patrick Shirkey]

Takashi Iwai wrote:

>  
> hmm, it's weird.  it would be nice if we can know at which point the
> driver became broken...
> 

It was working nicely before the drivers were merged but wouldn't paly 
with jack. Now it likes jack.

> 
> the attached patch will (hopefully) do the same thing as qinit in the
> kernel at the initialization (applied to the latest cvs).  please let
> me know whether it works.

Ouch. The latest cvs results in a hard lock when loading the usb-audio 
driver.





-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No! 
We want normal music!", I think that was more like acting than anything 
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: usbaudio won't do 24-bit or 32-bit i/o...

[Patrick Shirkey]

Patrick Shirkey wrote:
> Takashi Iwai wrote:
> 
>>  
>> hmm, it's weird.  it would be nice if we can know at which point the
>> driver became broken...
>>
> 
> It was working nicely before the drivers were merged but wouldn't paly 
> with jack. Now it likes jack.
> 

In additon to this the last version I had from before the merge that 
seemed to work well is from September 5. In that version I can record 
from inputs 1,2 and playback from all 4 channels.

I also get "sample format non available" when trying to use s24_3le with 
this version at any sample rate.





-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No! 
We want normal music!", I think that was more like acting than anything 
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: usbaudio won't do 24-bit or 32-bit i/o...

[Takashi Iwai]

At Tue, 17 Dec 2002 03:59:33 +0900,
Patrick Shirkey wrote:
> 
> Takashi Iwai wrote:
> 
> > 
> > the attached patch will (hopefully) do the same thing as qinit in the
> > kernel at the initialization (applied to the latest cvs).  please let
> > me know whether it works.
> 
> Ouch. The latest cvs results in a hard lock when loading the usb-audio 
> driver.

hmmm, it seems that the problem is on usb-uhci driver.
mysteriously, the midi part of quattro causes the kernel panic.  the
audio part seems ok.
you can avoid this either by using uhci driver or by commenting out
the entry for quattro in alsa-kernel/usb/usbquirks.h.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: usbaudio won't do 24-bit or 32-bit i/o...

[Patrick Shirkey]

Takashi Iwai wrote:
> 
> hmmm, it seems that the problem is on usb-uhci driver.
> mysteriously, the midi part of quattro causes the kernel panic.  the
> audio part seems ok.
> you can avoid this either by using uhci driver or by commenting out
> the entry for quattro in alsa-kernel/usb/usbquirks.h.
> 

I am trying it out on my ohci machine too and the latest driver has 
fixed the problem with not being able to capture from all the input.

Thanks.

I have commented out the midi quirk though in alsa-kernel/usb/usbquirk.h

I will be saving this cvs for sure.

The 24_3le support in arecord still captures the left channel maxed and 
the right at normal volume on pcm0 and pcm1.


-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No! 
We want normal music!", I think that was more like acting than anything 
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman



-------------------------------------------------------
This SF.NET email is sponsored by:  The Best Geek Holiday Gifts!
Time is running out!  Thinkgeek.com has the coolest gifts for
your favorite geek.   Let your fingers do the typing.   Visit Now.
T H I N K G E E K . C O M        http://www.thinkgeek.com/sf/

Re: usbaudio won't do 24-bit or 32-bit i/o...

[Takashi Iwai]

At Sat, 21 Dec 2002 07:00:45 +0900,
Patrick Shirkey wrote:
> 
> Takashi Iwai wrote:
> > 
> > hmmm, it seems that the problem is on usb-uhci driver.
> > mysteriously, the midi part of quattro causes the kernel panic.  the
> > audio part seems ok.
> > you can avoid this either by using uhci driver or by commenting out
> > the entry for quattro in alsa-kernel/usb/usbquirks.h.
> > 
> 
> I am trying it out on my ohci machine too and the latest driver has 
> fixed the problem with not being able to capture from all the input.
> 
> Thanks.
> 
> I have commented out the midi quirk though in alsa-kernel/usb/usbquirk.h
> 
> I will be saving this cvs for sure.
> 
> The 24_3le support in arecord still captures the left channel maxed and 
> the right at normal volume on pcm0 and pcm1.

did you update the alsa-lib, too?
there was a bug regarding 24bit conversion both on alsa-driver and
alsa-lib.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: usbaudio won't do 24-bit or 32-bit i/o...

[Patrick Shirkey]

Takashi Iwai wrote:
> At Sat, 21 Dec 2002 07:00:45 +0900,
> Patrick Shirkey wrote:
> 
>>Takashi Iwai wrote:
>>
>>>hmmm, it seems that the problem is on usb-uhci driver.
>>>mysteriously, the midi part of quattro causes the kernel panic.  the
>>>audio part seems ok.
>>>you can avoid this either by using uhci driver or by commenting out
>>>the entry for quattro in alsa-kernel/usb/usbquirks.h.
>>>
>>
>>I am trying it out on my ohci machine too and the latest driver has 
>>fixed the problem with not being able to capture from all the input.
>>
>>Thanks.
>>
>>I have commented out the midi quirk though in alsa-kernel/usb/usbquirk.h
>>
>>I will be saving this cvs for sure.
>>
>>The 24_3le support in arecord still captures the left channel maxed and 
>>the right at normal volume on pcm0 and pcm1.
> 
> 
> did you update the alsa-lib, too?
> there was a bug regarding 24bit conversion both on alsa-driver and
> alsa-lib.
> 

I updated all the cvs files and recompiled alsa-driver, alsa-lib and 
alsa-utils.

I will try again soon.




-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No! 
We want normal music!", I think that was more like acting than anything 
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: sb16 gets wedged when doing overlapped i/o (full duplex)

[John S. Denker]

     ==== This is a slightly-updated clone of item
     #636948 on the sourceforge bug/patch reporting
     system.  I'm moving it to here (the alsa-devel
     mailing list) at the request of Jaroslav. ====

When talking to Extigy on the USB bus:

    alsactl -f /tmp/foo store
alsactl: get_control:202: Cannot read control'2,0,0,Digital In Playback 
Source,0': Invalid argument
alsactl: get_control:202: Cannot read control '2,0,0,3D Stereo Extender 
Switch,0': Invalid argument
alsactl: get_control:202: Cannot read control '2,0,0,Up Down Switch,0': 
Invalid argument
alsactl: get_control:202: Cannot read control '2,0,0,Up Down Mode 
Select,0': Invalid argument

    alsactl -f /tmp/foo restore
alsactl: set_control:976: Cannot write control '2:0:0:Digital In 
Playback Source:134521100' : Invalid argument
alsactl: set_control:976: Cannot write control '2:0:0:3D Stereo Extender 
Switch:134521100' : Invalid argument
alsactl: set_control:976: Cannot write control '2:0:0:Up Down 
Switch:134521100' : Invalid argument
alsactl: set_control:976: Cannot write control '2:0:0:Up Down Mode 
Select:134521100' : Invalid argument

I modified alsactl to mke the foregoing errors non-fatal. That allowed
me to progress far enough to discover other errors, as reported a few
minutes ago.

Alsamixer also dies with "invalid argument".

I suspect this is a driver bug (as opposed to a utils bug) because I
suspect the driver is misinforming the utils as to what controls it
offers.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

hard crash when snd-ice1712 loads

[John S. Denker]

     ==== This is a slightly-updated clone of item
     #648063 on the sourceforge bug/patch reporting
     system.  I'm moving it to here (the alsa-devel
     mailing list) at the request of Jaroslav. ====

hard crash when snd-ice1712 loads

Using snd-ice1712 under rc6 (but not rc3) I observe:

    init.d/alsasound start
Starting sound driver: snd-ice1712 done

... and that's all she wrote.

The kernel crashes, hard.  It won't respond to
ctrl-alt-delete.  The num-lock light won't respond to
num-lock key.  (These symptoms are often associated with a
tight loop with the interrupts disabled.)

It is interesting to note that this card works fine under
rc3.  Unfortunately there has been a drastic rearrangement
of the code, so it won't be a simple matter of using diff
to highlight the differences.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: hard crash when snd-ice1712 loads

[Jaroslav Kysela]

On Thu, 5 Dec 2002, John S. Denker wrote:

>      ==== This is a slightly-updated clone of item
>      #648063 on the sourceforge bug/patch reporting
>      system.  I'm moving it to here (the alsa-devel
>      mailing list) at the request of Jaroslav. ====
> 
> hard crash when snd-ice1712 loads
> 
> Using snd-ice1712 under rc6 (but not rc3) I observe:
> 
>     init.d/alsasound start
> Starting sound driver: snd-ice1712 done
> 
> ... and that's all she wrote.
> 
> The kernel crashes, hard.  It won't respond to
> ctrl-alt-delete.  The num-lock light won't respond to
> num-lock key.  (These symptoms are often associated with a
> tight loop with the interrupts disabled.)
> 
> It is interesting to note that this card works fine under
> rc3.  Unfortunately there has been a drastic rearrangement
> of the code, so it won't be a simple matter of using diff
> to highlight the differences.

Note that this bug might be fixed in CVS. We found a few spinlock 
problems.

						Jaroslav

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



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: hard crash when snd-ice1712 loads

[Scott Bahling]

Hello -

I had the same problem until CVS post Dec 3rd. The problem started on
Nov 14 and has now gone away since Dec 3rd. I have a snapshot of the Dec
2nd CVS that crashes. The crash happens while alsactl does a restore. I
have not figured out which control it is trying to restore when the
crash happens yet.

Hardware: STAudio (Hoontech) DSP24 mkII

-scott 

On Thu, 2002-12-05 at 05:52, John S. Denker wrote:
>      ==== This is a slightly-updated clone of item
>      #648063 on the sourceforge bug/patch reporting
>      system.  I'm moving it to here (the alsa-devel
>      mailing list) at the request of Jaroslav. ====
> 
> hard crash when snd-ice1712 loads
> 
> Using snd-ice1712 under rc6 (but not rc3) I observe:
> 
>     init.d/alsasound start
> Starting sound driver: snd-ice1712 done
> 
> ... and that's all she wrote.
> 
> The kernel crashes, hard.  It won't respond to
> ctrl-alt-delete.  The num-lock light won't respond to
> num-lock key.  (These symptoms are often associated with a
> tight loop with the interrupts disabled.)
> 
> It is interesting to note that this card works fine under
> rc3.  Unfortunately there has been a drastic rearrangement
> of the code, so it won't be a simple matter of using diff
> to highlight the differences.
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

alsactl and alsamixer fail for extigy

[John S. Denker]

     ==== This is a slightly-updated clone of item
     #636948 on the sourceforge bug/patch reporting
     system.  I'm moving it to here (the alsa-devel
     mailing list) at the request of Jaroslav. ====

     It is also a duplicate of something I sent a
     few minutes ago with the wrong Subject: line.
     Sorry!


When talking to Extigy on the USB bus:

    alsactl -f /tmp/foo store
alsactl: get_control:202: Cannot read control'2,0,0,Digital In Playback 
Source,0': Invalid argument
alsactl: get_control:202: Cannot read control '2,0,0,3D Stereo Extender 
Switch,0': Invalid argument
alsactl: get_control:202: Cannot read control '2,0,0,Up Down Switch,0': 
Invalid argument
alsactl: get_control:202: Cannot read control '2,0,0,Up Down Mode 
Select,0': Invalid argument

    alsactl -f /tmp/foo restore
alsactl: set_control:976: Cannot write control '2:0:0:Digital In 
Playback Source:134521100' : Invalid argument
alsactl: set_control:976: Cannot write control '2:0:0:3D Stereo Extender 
Switch:134521100' : Invalid argument
alsactl: set_control:976: Cannot write control '2:0:0:Up Down 
Switch:134521100' : Invalid argument
alsactl: set_control:976: Cannot write control '2:0:0:Up Down Mode 
Select:134521100' : Invalid argument

I modified alsactl to mke the foregoing errors non-fatal. That allowed
me to progress far enough to discover other errors, as reported a few
minutes ago.

Alsamixer also dies with "invalid argument".

I suspect this is a driver bug (as opposed to a utils bug) because I
suspect the driver is misinforming the utils as to what controls it
offers.




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: alsactl and alsamixer fail for extigy

[Takashi Iwai]

Hi,

it became a quite late reply, since i caught a cold in the last
week and have been in bed...

At Thu, 05 Dec 2002 06:57:48 -0500,
John S. Denker <jsd@monmouth.com> wrote:
> 
> When talking to Extigy on the USB bus:
> 
>     alsactl -f /tmp/foo store
> alsactl: get_control:202: Cannot read control'2,0,0,Digital In Playback 
> Source,0': Invalid argument
> alsactl: get_control:202: Cannot read control '2,0,0,3D Stereo Extender 
> Switch,0': Invalid argument
> alsactl: get_control:202: Cannot read control '2,0,0,Up Down Switch,0': 
> Invalid argument
> alsactl: get_control:202: Cannot read control '2,0,0,Up Down Mode 
> Select,0': Invalid argument
> 
>     alsactl -f /tmp/foo restore
> alsactl: set_control:976: Cannot write control '2:0:0:Digital In 
> Playback Source:134521100' : Invalid argument
> alsactl: set_control:976: Cannot write control '2:0:0:3D Stereo Extender 
> Switch:134521100' : Invalid argument
> alsactl: set_control:976: Cannot write control '2:0:0:Up Down 
> Switch:134521100' : Invalid argument
> alsactl: set_control:976: Cannot write control '2:0:0:Up Down Mode 
> Select:134521100' : Invalid argument
> 
> I modified alsactl to mke the foregoing errors non-fatal. That allowed
> me to progress far enough to discover other errors, as reported a few
> minutes ago.
> 
> Alsamixer also dies with "invalid argument".
> 
> I suspect this is a driver bug (as opposed to a utils bug) because I
> suspect the driver is misinforming the utils as to what controls it
> offers.

perhaps yes -- don't you have any kernel error messages regarding
this? 
could you compile the alsa-driver with --with-debug=detect?  it will
give you more verbose debug messages.

i need the kernel error messages to know whether the parameters of
these mixer elements are correct, or whether the bug is in the usb
controller module.


thanks,

Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: sb16 gets wedged when doing overlapped i/o (full duplex)

[Uros Bizjak]

Hello!

  Did you try to set 16bit DMA allocation flag to Playback or Capture?

  Also, there are problems if your ISA bus is overclocked to more
than 8MHz.

	Uros.

On Thu, 5 Dec 2002, John S. Denker wrote:

> 	==== This is a slightly-updated clone of item
> 	#648232 on the sourceforge bug/patch reporting
> 	system.  I'm moving it to here (the alsa-devel
> 	mailing list) at the request of Jaroslav. ====
> 
> Things run OK for a few minutes (sometimes 30 seconds,
> sometimes 5+ minutes) then ALSA gets wedged.  Every read or
> write results in an error.  This only happens when I'm doing
> overlapped i/o; pure input runs happily for hours, and
> although I haven't tried it I assume pure output works fine.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: sb16 gets wedged when doing overlapped i/o (full duplex)

[John S. Denker]

Uros Bizjak wrote:

>   Did you try to set 16bit DMA allocation flag to Playback or Capture?

I tried setting it to Capture.
No joy.  ALSA gets wedged just the same as before.

By the way, is this DMA Allocation thingy documented anywhere?????

I had to do a huge find|grep to figure out what this
suggestion was referring to.  Alsamixer knows nothing
of this switch.  Amixer knows nothing of this switch.
Fortunately alsactl can deal with it.

 From the keen-grasp-of-the-obvious department:
This project would be a lot better off if there were
better documentation, and (some) comments in the code.
Why write the code if it's not going to be used?
If it's not documented, it's not going to be used!

>   Also, there are problems if your ISA bus is overclocked to more
> than 8MHz.

I haven't been messing with that.
But thanks for the hint; I'll fire up the oscilloscope and
take a look when I get a chance.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: sb16 gets wedged when doing overlapped i/o (full duplex)

[Uros Bizjak]

Hello!

> I tried setting it to Capture.
> No joy.  ALSA gets wedged just the same as before.
> 
> By the way, is this DMA Allocation thingy documented anywhere?????

  Yes, now it is mentioned in isa/sb/sb16_main.c driver source.

> I had to do a huge find|grep to figure out what this
> suggestion was referring to.  Alsamixer knows nothing
> of this switch.  Amixer knows nothing of this switch.
> Fortunately alsactl can deal with it.

  It is not a IFACE_MIXER switch, but IFACE_PCM type switch.

  From the error message you posted about this bug, it looks that driver
is trying to call prepare() operator on a substream that is still 
in SNDRV_PCM_STATE_RUNNING state. Perhaps Jaroslav could tell us if this
can happen if hardware pointers are not updated anymore (because sb16 DMA
engine gets stucked somehow). Do you get an XRUN message in
/var/log/messages?

	Uros.






-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: sb16 gets wedged when doing overlapped i/o (full duplex)

[Jaroslav Kysela]

On Thu, 5 Dec 2002, Uros Bizjak wrote:

> Hello!
> 
> > I tried setting it to Capture.
> > No joy.  ALSA gets wedged just the same as before.
> > 
> > By the way, is this DMA Allocation thingy documented anywhere?????
> 
>   Yes, now it is mentioned in isa/sb/sb16_main.c driver source.
> 
> > I had to do a huge find|grep to figure out what this
> > suggestion was referring to.  Alsamixer knows nothing
> > of this switch.  Amixer knows nothing of this switch.
> > Fortunately alsactl can deal with it.
> 
>   It is not a IFACE_MIXER switch, but IFACE_PCM type switch.
> 
>   From the error message you posted about this bug, it looks that driver
> is trying to call prepare() operator on a substream that is still 
> in SNDRV_PCM_STATE_RUNNING state. Perhaps Jaroslav could tell us if this
> can happen if hardware pointers are not updated anymore (because sb16 DMA
> engine gets stucked somehow). Do you get an XRUN message in
> /var/log/messages?

Prepare can be called with status different than SNDRV_PCM_STATE_OPEN and 
SNDRV_PCM_STATE_RUNNING. You have to call snd_pcm_drop() and 
snd_pcm_drain() in this case. Ten second limit is in write() and read() 
syscalls, so it's possible that the SB DMA engine is somehow screwed.

						Jaroslav

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



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: sb16 gets wedged when doing overlapped i/o (full duplex)

[John S. Denker]

Uros Bizjak wrote:

>   From the error message you posted about this bug, it looks that driver
> is trying to call prepare() operator on a substream that is still
> in SNDRV_PCM_STATE_RUNNING state. Perhaps Jaroslav could tell us if this
> can happen if hardware pointers are not updated anymore (because sb16 DMA
> engine gets stucked somehow). Do you get an XRUN message in
> /var/log/messages?

Excellent question!

1) No xrun messages in /var/log/messages, but....

2) My program intentionally causes an overrun on input once
every 0.5 seconds.  It catches this condition, and recovers
by calling snd_pcm_prepare().  It does not print a message
about this (unless super-specially requested).

I realize that other programs may cause far fewer overruns,
which may (or may not :-) explain why others don't suffer
quite so badly from this bug.  Even so, it remains a bug.
An overrun shouldn't take down the whole system.

3) As previously indicated, if I load the system, I can cause
a few audible underruns on output.  But doing this has no
discernible effect on the incidence of the bug in question.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: sb16 gets wedged when doing overlapped i/o (full duplex)

[Uros Bizjak]

Hello!

> >   From the error message you posted about this bug, it looks that driver
> > is trying to call prepare() operator on a substream that is still
> > in SNDRV_PCM_STATE_RUNNING state. Perhaps Jaroslav could tell us if this
> > can happen if hardware pointers are not updated anymore (because sb16 DMA
> > engine gets stucked somehow). Do you get an XRUN message in
> > /var/log/messages?
> 
> 2) My program intentionally causes an overrun on input once
> every 0.5 seconds.  It catches this condition, and recovers
> by calling snd_pcm_prepare().  It does not print a message
> about this (unless super-specially requested).

  ISA SoundBlasters have numerous hardware problems in full-duplex mode,
one of them is triggered by switching capture channel from 8bit full
duplex to 16bit (this can be avoided by setting "16bit DMA allocation"
switch), sample transfers will be corrupt on overclocked ISA bus. In
your case, it looks that in full duplex mode, sometimes stopping one
channel stops the other too, and then sb16 chip won't react on
DMA_ON/DMA_OFF commands anymore. Strange.

  Could you put a printk() in snd_sb16_*_pointer() functions
(sb16_main.c souce)? This printk() should print dma channel and value of
ptr, so we can see when/if DMA channels gets stuck.

  BTW: It looks like another sb16 hardware bug to me. On module re-load,
drivers reset sb16 chip, that is why module reload helps.

  Perhaps you can derive a small test case from your application, which
will help developers to stresstest soundcard and perhaps PCM layer?

	Uros.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: sb16 gets wedged when doing overlapped i/o (full duplex)

[John S. Denker]

[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]

Uros Bizjak wrote:

>   Could you put a printk() in snd_sb16_*_pointer() functions
> (sb16_main.c souce)? This printk() should print dma channel and value of
> ptr, so we can see when/if DMA channels gets stuck.

Done.  The result put 2.6 megabytes into /var/log/messages.
The head -10 and tail -50 of the relevant section is
attached below;  if anybody wants more detail the whole
shebang is available at
   http://www.av8n.net/~jsd/alsa/messages.txt

>   BTW: It looks like another sb16 hardware bug to me. On module re-load,
> drivers reset sb16 chip, that is why module reload helps.

Plausible....  But note that the cs4239 module gets i/o
errors when provoked by the same program, so there may
be driver design weaknesses involved, too.

> Perhaps you can derive a small test case from your application, which
> will help developers to stresstest soundcard and perhaps PCM layer?

My program is not super-small, but the relevant
passages are simple and easy to find.
You can help yourself at
   http://www.monmouth.com/~jsd/turbid/

Compile the thing and invoke it as
   ./turbid -F 440
or
   ./turbid -v -F 440

Note that just for you I added the --snooze <tt>
option, which will cause it to generate an
overrun every <tt> seconds (default .5) PROVIDED
<tt> is not too small.

[-- Attachment #2: msgs.txt --]
[-- Type: text/plain, Size: 4308 bytes --]

Dec  6 06:51:58 moat2 jsd: about to start ....
Dec  6 06:52:03 moat2 turbid: PID file "/var/run/turbid.pid" already exists, not overwriting
Dec  6 06:52:03 moat2 kernel: snd_sb16_capture_pointer  dma: 5 ptr: 8
Dec  6 06:52:03 moat2 kernel: snd_sb16_capture_pointer  dma: 5 ptr: 4110
Dec  6 06:52:03 moat2 kernel: snd_sb16_capture_pointer  dma: 5 ptr: 4894
Dec  6 06:52:03 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 11
Dec  6 06:52:03 moat2 kernel: snd_sb16_capture_pointer  dma: 5 ptr: 8206
Dec  6 06:52:03 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 2055
Dec  6 06:52:03 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 2239
Dec  6 06:52:03 moat2 kernel: snd_sb16_capture_pointer  dma: 5 ptr: 12302
....
Dec  6 06:57:59 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 4129
Dec  6 06:57:59 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 6151
Dec  6 06:57:59 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 6176
Dec  6 06:57:59 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 6
Dec  6 06:57:59 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 33
Dec  6 06:57:59 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 2053
Dec  6 06:57:59 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 2081
Dec  6 06:58:00 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 4103
Dec  6 06:58:00 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 5861
Dec  6 06:58:00 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 6151
Dec  6 06:58:00 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 6317
Dec  6 06:58:00 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 7
Dec  6 06:58:00 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 34
Dec  6 06:58:00 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 2055
Dec  6 06:58:00 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 2081
Dec  6 06:58:00 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 4103
Dec  6 06:58:00 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 4129
Dec  6 06:58:00 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 6151
Dec  6 06:58:00 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 6177
Dec  6 06:58:00 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 7
Dec  6 06:58:00 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 242
Dec  6 06:58:00 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 2055
Dec  6 06:58:00 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 2083
Dec  6 06:58:00 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 4103
Dec  6 06:58:00 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 4129
Dec  6 06:58:00 moat2 kernel: snd_sb16_capture_pointer  dma: 5 ptr: 6
Dec  6 06:58:00 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 6155
Dec  6 06:58:00 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 7893
Dec  6 06:58:00 moat2 kernel: snd_sb16_capture_pointer  dma: 5 ptr: 4210
Dec  6 06:58:00 moat2 kernel: snd_sb16_capture_pointer  dma: 5 ptr: 4386
Dec  6 06:58:10 moat2 turbid[4903]: Calout wrote 8820 got -5
Dec  6 06:58:10 moat2 kernel: snd_sb16_capture_pointer  dma: 5 ptr: 8192
Dec  6 06:58:10 moat2 kernel: snd_sb16_capture_pointer  dma: 5 ptr: 8192
Dec  6 06:58:10 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 0
Dec  6 06:58:10 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 0
Dec  6 06:58:20 moat2 kernel: snd_sb16_capture_pointer  dma: 5 ptr: 8192
Dec  6 06:58:20 moat2 turbid[4903]: Calout wrote 8820 got -5
Dec  6 06:58:20 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 0
Dec  6 06:58:30 moat2 turbid[4902]: Read_stuff requested 2048 got -5: Input/output error
Dec  6 06:58:30 moat2 turbid[4902]: turbid exiting, status 1
Dec  6 06:58:30 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 0
Dec  6 06:58:49 moat2 jsd: program has exited due to i/o error
Dec  6 06:59:10 moat2 jsd: will restart it just for fun
Dec  6 06:59:15 moat2 turbid: PID file "/var/run/turbid.pid" already exists, not overwriting
Dec  6 06:59:15 moat2 kernel: snd_sb16_capture_pointer  dma: 5 ptr: 8
Dec  6 06:59:15 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 11
Dec  6 06:59:25 moat2 turbid[4908]: Read_stuff requested 2048 got -5: Input/output error
Dec  6 06:59:25 moat2 turbid[4908]: turbid exiting, status 1
Dec  6 06:59:25 moat2 kernel: snd_sb16_playback_pointer dma: 1 ptr: 2048
Dec  6 06:59:29 moat2 jsd: program has exited due to i/o error

cs4239 errs on full duplex (provoked by overruns?)

[John S. Denker]

The same program that causes sb16 to become completely
wedged causes milder errors in the cs4239 module.
Reference:  see thread starting at:
http://www.mail-archive.com/alsa-devel@lists.sourceforge.net/msg05525.html

The program runs for a while (sometimes 8 minutes,
sometimes less than one minute) and then gets an
i/o error.  This differs in at least three ways from
the sb16 scenario:
  -- usually it gets the i/o error without having
generated any IOCTL_PREPARE() errors.
  -- On rare occasions it does generate IOCTL_PREPARE()
errors, but they are not fatal.
  -- The ALSA system does not get totally wedged;
restarting the userland application gets us back
where we started.

However one may conjecture that there are elements in
common here.  My program is continually doing input and
output at the same time (i.e. full duplex) ... and is
causing input overruns once every 0.5 seconds.  It is
perhaps a good diagnostic for detecting drivers that
don't quite do enough clean-up after an overrun.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: sb16 gets wedged when doing overlapped i/o (full duplex)

[Paul Davis]

> From the keen-grasp-of-the-obvious department:
>This project would be a lot better off if there were
>better documentation, and (some) comments in the code.
>Why write the code if it's not going to be used?
>If it's not documented, it's not going to be used!

actually, i have to note that this is not so obvious. there are *many*
people using ALSA. we've all sworn our way through the process. 

there is *no* point in reminding this list about the need for
documentation. the current state is pitiful, though just barely
adequate to get people started. many folks seem to think there is a
large group of people working on ALSA: there is not. it consists at
this time of just jaroslav and takashi as "full time" people, clemens
doing a fabulous job with some deep patch work, and then a few others
like myself dropping by with driver patches and occasionally new
patches. at this point hardly any of the linux-sound crew that has
held together the kernel's OSS-derived system have switched to working
on ALSA. patrick has done a great job improving what's on the website,
but there is still a long way to go. he has set up a system where you
can add to the per-card documentation yourself, which is a good place
to begin.

--p


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: sb16 gets wedged when doing overlapped i/o (full duplex)

[Takashi Iwai]

At Thu, 05 Dec 2002 10:23:08 -0500,
Paul Davis wrote:
> 
> > From the keen-grasp-of-the-obvious department:
> >This project would be a lot better off if there were
> >better documentation, and (some) comments in the code.
> >Why write the code if it's not going to be used?
> >If it's not documented, it's not going to be used!
> 
> actually, i have to note that this is not so obvious. there are *many*
> people using ALSA. we've all sworn our way through the process. 
> 
> there is *no* point in reminding this list about the need for
> documentation. the current state is pitiful, though just barely
> adequate to get people started. many folks seem to think there is a
> large group of people working on ALSA: there is not. it consists at
> this time of just jaroslav and takashi as "full time" people, clemens
> doing a fabulous job with some deep patch work, and then a few others
> like myself dropping by with driver patches and occasionally new
> patches. at this point hardly any of the linux-sound crew that has
> held together the kernel's OSS-derived system have switched to working
> on ALSA. patrick has done a great job improving what's on the website,
> but there is still a long way to go. he has set up a system where you
> can add to the per-card documentation yourself, which is a good place
> to begin.

thanks Paul, a nice counterargument :)


regarding 16bit DMA mode:
there was some descriptions about this switch.
together with the change of ALSA structure and the API, the
implementation of 16bit DMA mode switch has been changed much, too,
and the description was removed since it's obsolete.  and it wasn't a
big problem because less and less people are using the sb card
nowadays...


i'm thinking of starting ALSA-howto project again for a new ALSA
version.  then such info will go there.


ciao,

Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

documentation or lack thereof

[John S. Denker]

I wrote:
 >>From the keen-grasp-of-the-obvious department:
 >>This project would be a lot better off if there were
 >>better documentation, and (some) comments in the code.


Then on Thu, 05 Dec 2002 10:23:08 -0500, Paul Davis wrote:
 >
 >actually, i have to note that this is not so obvious. there are *many*
 >people using ALSA. we've all sworn our way through the process.
 >there is *no* point in reminding this list about the need for
 >documentation. the current state is pitiful, ...
 >  many folks seem to think there is a
 >large group of people working on ALSA: there is not.

I have tried and failed to understand that remark.  I
stumble over the following apparent inconsistencies:
  ++ On one hand we agree that the current state is pitiful.
  ++ I would think and hope that reminders are almost
     unnecessary because the pitifulness is so obvious.
  -- But why start out by saying it is not obvious?
  -- Usually swearing is not considered a good thing.
  -- And note that if the documentation were better,
     more people would be willing and able to help
     work on the project!  In a collaborative project,
     lack of documentation and short-handedness create
     a vicious circle!

To look at the same glass from the half-full perspective,
Takashi wrote:

> recently i wrote a small howto for writing an alsa-driver.  

That's good!

> please check the archive of alsa-devel ml.

It would be even better if the howto were integrated into
the project package, not hiding in a list archive somewhere.
Maybe even comments in the code linking to the howto, so
people can find it when they need it.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: documentation or lack thereof

[Takashi Iwai]

At Mon, 09 Dec 2002 09:54:10 -0500,
John S. Denker <jsd@monmouth.com> wrote:
> 
> To look at the same glass from the half-full perspective,
> Takashi wrote:
> 
> > recently i wrote a small howto for writing an alsa-driver.  
> 
> That's good!
> 
> > please check the archive of alsa-devel ml.
> 
> It would be even better if the howto were integrated into
> the project package, not hiding in a list archive somewhere.

yes, of course, it will go into some cvs tree in near future.
it's just a draft version, and i'd like to put it in other formats.

> Maybe even comments in the code linking to the howto, so
> people can find it when they need it.

the comments in the driver code are also one of TODOs.
we need the comments at least for each exported function written in
kernel (java-)doc style.
i personlly think it would be better to copy & paste the text to the
corresponding part than to put a link to howto.


ciao,

Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: documentation or lack thereof

[ljp]

On Monday 09 December 2002 07:54 am, John S. Denker wrote:
> I wrote:
>  >>From the keen-grasp-of-the-obvious department:
>  >>This project would be a lot better off if there were
>  >>better documentation, and (some) comments in the code.
>
> Then on Thu, 05 Dec 2002 10:23:08 -0500, Paul Davis wrote:
>  >actually, i have to note that this is not so obvious. there are *many*
>  >people using ALSA. we've all sworn our way through the process.
>  >there is *no* point in reminding this list about the need for
>  >documentation. the current state is pitiful, ...
>  >  many folks seem to think there is a
>  >large group of people working on ALSA: there is not.
>

This is quite funny, as I havent looked into alsa dev for quite some time 
(months.. years?), and lo and behold what did I find?
Dev Documentation for .9! Not only that, but two of my cards (rme digi96-pst 
and tascam 428) have alsa drivers. So. with that. I am going to start working 
on this desktop sound app again.
Woot!


-- 
My cat's a debugger....

Potter, Lorn, "ljp"
core developer / Web Administrator
Project OPIE- the Open Palmtop Integrated Environment
http://opie.handhelds.org | http://www.opie.info (german) |
http://www.opie.us
IRC: irc.freenode.net #opie #opie.de

llornkcor@handhelds.org


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: documentation or lack thereof

[Paul Davis]

> >actually, i have to note that this is not so obvious. there are *many*
> >people using ALSA. we've all sworn our way through the process.
> >there is *no* point in reminding this list about the need for
> >documentation. the current state is pitiful, ...
> >  many folks seem to think there is a
> >large group of people working on ALSA: there is not.
>
>I have tried and failed to understand that remark.  I
>stumble over the following apparent inconsistencies:
>  ++ On one hand we agree that the current state is pitiful.
>  ++ I would think and hope that reminders are almost
>     unnecessary because the pitifulness is so obvious.
>  -- But why start out by saying it is not obvious?

because its not clear to me that a lot more people would be using ALSA
today if it had been better documented over the last year or so. the
central problems with using ALSA over the last 12-18 months have not
really been lack of documentation but lack of API stability.

>  -- Usually swearing is not considered a good thing.

and it wasn't this time either. my point was merely that quite a
number of us having written applications of varying degrees of
sophistication around ALSA without any documentation. it was painful,
very painful during the time that jaroslav and abramo kept changing
the API, but it has become a lot less so nowadays. the problem is
there is still no documentation to make it easier for people starting
to use ALSA now, and those of us who have figured it out no longer
have the motivation to write it.

>  -- And note that if the documentation were better,
>     more people would be willing and able to help
>     work on the project!  In a collaborative project,
>     lack of documentation and short-handedness create
>     a vicious circle!

i disagree. there seem to be very few people interested in working on
alsa-kernel or alsa-lib. most people want a nice, easy to use API so
that they can dump sounds to an audio interface or possibly record
them. the number of people with the skills, knowledge and interest in
working on ALSA has always been remarkably low.

on the other hand, having more documentation is almost always a good
thing. now, where are the volunteers?

--p






-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: documentation or lack thereof

[Patrick Shirkey]

Paul Davis wrote:

> i disagree. there seem to be very few people interested in working on
> alsa-kernel or alsa-lib. most people want a nice, easy to use API so
> that they can dump sounds to an audio interface or possibly record
> them. the number of people with the skills, knowledge and interest in
> working on ALSA has always been remarkably low.
> 
> on the other hand, having more documentation is almost always a good
> thing. now, where are the volunteers?
> 

Lot's of possible flames here but the main thing is that the people who 
do understand the alsa-driver well enough are either too busy to find 
the time or have justifiable reservations about getting their prose online.

Mailing lists are much better for these people than official documents.

Unfortunately the people like myself are not in a position to edit large 
amounts of code documentation which we scour from the lists. I can 
however do a reasonable attempt at formatting the stuff. However I don't 
have much time or inclination to learn docbook at the moment so it 
wouldn't be a standard format.

But it will probably help people if I put the basics up on line. So I 
will do some work on it over the next few days.

AFAIK there is only one other person round here who has the motivation 
and skills to do the docbook work and he must be busy at the moment or 
found other things to do.

Anyway against all odds the past year has netted us the alsa-docs, 
alsa-wiki, Paul and Matthias's basic programming howtos, Takashi's 
desription of how to build a driver which equal 5 new docs. Not bad at all.

The only thing we need now is an indepth doc on doing midi programming 
which Juan Linetsky has started but has declined offering it to the public.


-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No! 
We want normal music!", I think that was more like acting than anything 
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

soundcard matrix: broken links etc.

[John S. Denker]

Hi --

The soundcard matrix needs attention.
   http://www.alsa-project.org/~goemon/

I ran a basic link-checker on it.
The error-log is so large that I hesitate to
send the whole thing by email.  Here's the summary:

Code Occurrences What to do
200	 1 There are broken fragments which must be fixed.
301	 2 You should update the link.
302 	27 Usually nothing.
401	 4 The link is not public. You'd better specify it.
403	 1 The link is forbidden! This needs fixing.
404 	64 The link is broken. Fix it NOW!
500 	38 Either the hostname is incorrect or ...

You can grab the details from
   http://www.av8n.net/~jsd/alsa/checked-links.html.gz
   http://www.av8n.net/~jsd/alsa/checked-links.html

====================

HINT:  There are decent link-checkers available for free,
e.g. http://validator.w3.org/checklink

It wouldn't hurt to run them once in a while.....



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: soundcard matrix: broken links etc.

[Patrick Shirkey]

John S. Denker wrote:
> Hi --
> 
> The soundcard matrix needs attention.
>   http://www.alsa-project.org/~goemon/
> 

This version is now deprecated. How did you get access to it? I noticed 
the other day that google search for ALSA lists this page as second.

We should make the index for geomon point to it too. Jaroslav or Dan can 
you do that?

If it was through a link on the site I will squash it.




-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No! 
We want normal music!", I think that was more like acting than anything 
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: soundcard matrix: broken links etc.

[John S. Denker]

Patrick Shirkey wrote:

> >   http://www.alsa-project.org/~goemon/

> How did you get access to it? 

Google.

> This version is now deprecated. 

Point taken.
However, the apparently non-deprecated version
   http://www.alsa-project.org/alsa-doc/
contains almost as many broken links etc.
Here's the summary:

  Code Occurrences  What to do
  200     1         There are broken fragments which must be fixed.
  301     1         You should update the link.
  302     28        Usually nothing.
  401     4         The link is not public. You'd better specify it.
  403     1         The link is forbidden! This needs fixing.
  404     57        The link is broken. Fix it NOW!
  405     1         The server does not allow HEAD requests.
  500     37        Either the hostname is incorrect or ...

Interested parties may grab the details from
   http://www.av8n.net/~jsd/alsa/checked-links2.html
   http://www.av8n.net/~jsd/alsa/checked-links2.html.gz



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: soundcard matrix: broken links etc.

[Patrick Shirkey]

John S. Denker wrote:

> However, the apparently non-deprecated version
>   http://www.alsa-project.org/alsa-doc/
> contains almost as many broken links etc.
> Here's the summary:
> 
>  Code Occurrences  What to do
>  200     1         There are broken fragments which must be fixed.
>  301     1         You should update the link.
>  302     28        Usually nothing.
>  401     4         The link is not public. You'd better specify it.
>  403     1         The link is forbidden! This needs fixing.
>  404     57        The link is broken. Fix it NOW!
>  405     1         The server does not allow HEAD requests.
>  500     37        Either the hostname is incorrect or ...
> 
> Interested parties may grab the details from
>   http://www.av8n.net/~jsd/alsa/checked-links2.html
>   http://www.av8n.net/~jsd/alsa/checked-links2.html.gz
> 

Thanks for that. If you have the inclination to send in a patch that 
would be very appreciated. Otherwise it will have to wait for me to get 
some more time.


-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No! 
We want normal music!", I think that was more like acting than anything 
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: soundcard matrix: broken links etc.

[John S. Denker]

Patrick Shirkey wrote:


 > >   http://www.alsa-project.org/alsa-doc/
 > > contains almost as many broken links etc.
 >
 > Thanks for that. If you have the inclination to send in a patch that
 > would be very appreciated.

Not a patch, but the whole thing fixed up:
You can grab it from
   http://www.av8n.net/~jsd/alsa/matrix.html

Changes include:
  -- dead links have been removed
  -- support status is now indicated in the notes,
     not just in the color-coding,
     so that the matrix is useful if you have a
     text-only browser and/or a black&white printer.
  -- i/o support notes are now more mnemonic



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/