Re: [Alsa-devel] AudioTrak Optoplay...
On Friday 06 June 2003 02:35, Takashi Iwai wrote: > > > the changes were committed to cvs now, so please give a try. > > > > The changes you made allowed me to play sound through the device, but > > I still get those usb-check-bandwidth messages, regardless of whether > > or not I used the "nrpacks=2" option for the snd-usb-audio module. Is > > there anything else we can try? The driver is usable as-is, but all > > those messages fill up the syslog pretty quick. > > to be sure, please check /proc/asound/card0/stream0 while playback > and how much URB packets are being used. > Sorry for the delay in getting back to you; work very rudely intruded on my life last week..;) Regarding your request, the relevant line from stream0 looks like: URBs = 5 [ 2 2 2 2 2 ] Without the nrpacks=2 option, the URB line looks like: URBs = 5 [ 4 4 4 4 4 ] I should point out that things have apparently changed some in the last week. Using the code I checked out of CVS just a few hours ago, I no longer get continuous messages in the syslog. Instead I seem to get a few lines of those usb-check-bandwidth messages each time a new song is loaded by xmms. Then, while the song is playing, I will get occasional breaks in the sound accompanied by a few messages in the syslog similar to the following: Jun 12 23:36:58 snoopy kernel: usb.c: usb-check-bandwidth would have FAILED: was 912, would be 1140, bustime = 228 us Jun 12 23:36:59 snoopy last message repeated 715 times Jun 12 23:36:59 snoopy kernel: usb-uhci.c: iso_find_start: gap in seamless isochronous scheduling Jun 12 23:36:59 snoopy kernel: usb.c: usb-check-bandwidth would have FAILED: was 912, would be 1140, bustime = 228 us Jun 12 23:37:19 snoopy last message repeated 10003 times Jun 12 23:37:19 snoopy kernel: usb-uhci.c: iso_find_start: gap in seamless isochronous scheduling Jun 12 23:37:19 snoopy kernel: usb.c: usb-check-bandwidth would have FAILED: was 912, would be 1140, bustime = 228 us Also, a dialog box will sometimes pop up saying "snd_pcm_wait: Input/output error" -Ross --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] AudioTrak Optoplay...
At Fri, 6 Jun 2003 00:34:53 -0600, Ross Miller wrote: > > On Wednesday 04 June 2003 06:47, Takashi Iwai wrote: > > > a possible reason is that either we set up the interface correctly, or > > we pass too many packets for the requested status. > > i added nrpacks module option in usbaudio driver. please set > > nrpacks=2 to reduce the max number of URB packets. > > > > the changes were committed to cvs now, so please give a try. > > > The changes you made allowed me to play sound through the device, but I > still get those usb-check-bandwidth messages, regardless of whether or not > I used the "nrpacks=2" option for the snd-usb-audio module. Is there > anything else we can try? The driver is usable as-is, but all those > messages fill up the syslog pretty quick. to be sure, please check /proc/asound/card0/stream0 while playback and how much URB packets are being used. the message can be disabled if you build the kernel without CONFIG_USB_DEBUG, btw. > Also, although a volume control shows up in alsamixer (and that's all that > shows up in alsamixer) it doesn't seem to affect the sound coming out of > the optical port; it only controls sound coming out of the analog > headphone jack. if you change a DAC volume, it should not affect the "digital" outs :) Takashi --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] AudioTrak Optoplay...
On Wednesday 04 June 2003 06:47, Takashi Iwai wrote: > a possible reason is that either we set up the interface correctly, or > we pass too many packets for the requested status. > i added nrpacks module option in usbaudio driver. please set > nrpacks=2 to reduce the max number of URB packets. > > the changes were committed to cvs now, so please give a try. > The changes you made allowed me to play sound through the device, but I still get those usb-check-bandwidth messages, regardless of whether or not I used the "nrpacks=2" option for the snd-usb-audio module. Is there anything else we can try? The driver is usable as-is, but all those messages fill up the syslog pretty quick. Also, although a volume control shows up in alsamixer (and that's all that shows up in alsamixer) it doesn't seem to affect the sound coming out of the optical port; it only controls sound coming out of the analog headphone jack. I don't know if this is a limitation of the hardware, or if something in the software isn't getting set correctly. It'd be nice to have a software volume control for the optical out, though. Thanks, -Ross --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] AudioTrak Optoplay...
Ross Miller wrote: > On Tuesday 03 June 2003 01:03, Clemmens Ladisch wrote: > > Are you sure that the Optoplay supports _one_-channel output? > > > That's a good question - I'll try a stereo WAV later this evening after I get > off work. It doesn't, but your aplay command used the "default" device which automatically converts unsupported sample formats. Anyway, the problem is with the sample rate. > lsusb -v: > [... many lines ...] > BTW: Is there any documentation available that explains what all these > fields mean? The official documentation for this are the USB 2.0 Specification, the USB Audio Specifications, and the USB Human Interface Device Specification from www.usb.org, but those are not quite easy to parse. HTH Clemens --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] AudioTrak Optoplay...
At Mon, 2 Jun 2003 14:18:26 -0600, Ross Miller wrote: > > Also, the following lines are printed in the syslog: > May 24 23:28:17 snoopy kernel: usb-uhci.c: interrupt, status 2, frame# 985 > May 24 23:28:18 snoopy kernel: usb_control/bulk_msg: timeout > May 24 23:28:18 snoopy kernel: ALSA ../alsa-kernel/usb/usbaudio.c:1026: 5:1:2: > cannot get freq at ep 0x1 > > I looked at the source code, and line 1026 is in the init_usb_sample_rate > function. According to the comment, the calls are made > only if the devices has "sampling rate control" . I hacked that part out (so > that the function no longer tries to set the rate) and then the device played > just fine, at 24, 16 and 8 bits. ok, i added a workaround code in usbaudio.c. > The only problem was that it spat out a > continuous stream of messages to the syslog. Here's a sample: > > May 24 23:44:32 snoopy last message repeated 3 times > May 24 23:44:32 snoopy kernel: usb.c: usb-check-bandwidth would have FAILED: > was 456, would be 913, bustime = 457 us > May 24 23:44:32 snoopy kernel: usb.c: usb-check-bandwidth would have FAILED: > was 799, would be 913, bustime = 114 us > May 24 23:44:32 snoopy last message repeated 3 times > May 24 23:44:33 snoopy kernel: usb.c: usb-check-bandwidth would have FAILED: > was 456, would be 913, bustime = 457 us > > These messages continue for as long as the sound is playing. a possible reason is that either we set up the interface correctly, or we pass too many packets for the requested status. i added nrpacks module option in usbaudio driver. please set nrpacks=2 to reduce the max number of URB packets. the changes were committed to cvs now, so please give a try. ciao, Takashi --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] AudioTrak Optoplay...
On Tuesday 03 June 2003 01:03, Clemmens Ladisch wrote: > > CHANNELS: 1 > > ... > > Are you sure that the Optoplay supports _one_-channel output? > That's a good question - I'll try a stereo WAV later this evening after I get off work. > Please post the contents of /proc/asound/cardX/stream0 and the output of > "lsusb -v". > /proc/asound/OptoPlay/stream0: Ego Systems Inc. AUDIOTRAK OptoPlay at usb-00:07.2-1 : USB Audio Playback: Status: Stop Interface 1 Altset 1 Format: S16_LE Channels: 2 Endpoint: 1 OUT (ADAPTIVE) Rates: 32000, 44100, 48000, 64000, 88200, 96000 Interface 1 Altset 2 Format: S24_3LE Channels: 2 Endpoint: 1 OUT (ADAPTIVE) Rates: 32000, 44100, 48000, 64000, 88200, 96000 lsusb -v: Bus 001 Device 001: ID : Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.00 bDeviceClass9 Hub bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x idProduct 0x bcdDevice0.00 iManufacturer 0 iProduct2 USB UHCI Root Hub iSerial 1 1400 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x40 Self Powered MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type none wMaxPacketSize 8 bInterval 255 Language IDs: (length=4) (null)((null)) Bus 001 Device 002: ID 0a92:0053 EGO SYStems, Inc. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.00 bDeviceClass0 Interface bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0a92 EGO SYStems, Inc. idProduct 0x0053 bcdDevice1.00 iManufacturer 1 Ego Systems Inc. iProduct2 AUDIOTRAK OptoPlay iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 201 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 1 Control Device bInterfaceProtocol 0 iInterface 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType36 bDescriptorSubtype 1 (HEADER) bcdADC 1.00 wTotalLength 40 bInCollection 1 baInterfaceNr( 0) 1 AudioControl Interface Descriptor: bLength12 bDescriptorType36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 1 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bNrChannels 2 wChannelConfig 0x0003 Left Front (L) Right Front (R) iChannelNames 0 iTerminal 0 AudioControl Interface Descriptor: bLength10 bDescriptorType36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 2 bSourceID 1 bControlSize1 bmaControls( 0) 0x00 bmaControls( 0) 0x03 Mute Volume bmaControls( 0) 0x03 Mute Volume iFeature0 AudioControl Interface Descriptor: bLength 9 bDescriptorType36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 3 wTerminalType 0x0301 Speaker bAssocTerminal 0 bSourceID 2 iTerminal 0 Interface Descriptor: bLength 9 bDescriptorType
Re: [Alsa-devel] AudioTrak Optoplay...
Ross Miller wrote: > There was a thread on the alsa-user list back in March discussing Audiotrack > products, and specifically the Optoplay USB device. The relevant bits are: > > >> The Optoplay, listed as '?' on the matrix, seemed to work OK, the drivers > >> loaded but - no sound output. This is the same as the problem someone > >> reported a coulpe of months ago - it only works at 24 bits, and while the > >> driver loads, apps only try to open the device @ 16 bits, which doesn't > >>work. > > > >This is only for OSS apps. ALSA programs (e.g. aplay) probably would have > >worked. > > Having just tried it out on version 0.9.3c, I can confirm that the optoplay > DOESN'T work, even at 24 bits, using aplay. However, it can be made to work > with a quick hack to the driver code. I'll get to that below. First, here's > the errors I get from aplay: > > snoopy:/usr/local/alsa/bin # ./aplay ~/24bit.wav > Playing WAVE '/root/24bit.wav' : Signed 24 bit Little Endian in 3bytes, Rate > 44100 Hz, Mono > ALSA lib pcm_hw.c:436:(snd_pcm_hw_prepare) SNDRV_PCM_IOCTL_PREPARE failed: > Connection timed out > aplay: set_params:840: Unable to install hw params: > ACCESS: RW_INTERLEAVED > FORMAT: S24_3LE > SAMPLE_BITS: 24 > CHANNELS: 1 > ... Are you sure that the Optoplay supports _one_-channel output? > Also, the following lines are printed in the syslog: > May 24 23:28:17 snoopy kernel: usb-uhci.c: interrupt, status 2, frame# 985 > May 24 23:28:18 snoopy kernel: usb_control/bulk_msg: timeout > May 24 23:28:18 snoopy kernel: ALSA ../alsa-kernel/usb/usbaudio.c:1026: 5:1:2: > cannot get freq at ep 0x1 > > I looked at the source code, and line 1026 is in the init_usb_sample_rate > function. According to the comment, the calls are made > only if the devices has "sampling rate control" . I hacked that part out (so > that the function no longer tries to set the rate) and then the device played > just fine, at 24, 16 and 8 bits. The only problem was that it spat out a > continuous stream of messages to the syslog. Here's a sample: > > May 24 23:44:32 snoopy kernel: usb.c: usb-check-bandwidth would have FAILED: > was 456, would be 913, bustime = 457 us > ... > These messages continue for as long as the sound is playing. > > It looks to me like the audioformat structure is being set wrong for this > device. Specifically, the EP_CS_ATTR_SAMPLE_RATE attribute is set when it > probably shouldn't be. Hmm, this flag is to be set by the device in its USB descriptors if it supports sampling rate control. Please post the contents of /proc/asound/cardX/stream0 and the output of "lsusb -v". > And can we find a way to set the audioformat structure properly? Yes; the Optoplay isn't the only device with (apparently) broken descriptors. > Also, what do all the usb-check-bandwidth messages mean? The device sends or receives more data than it should. Probably because the sampling rate isn't set correctly ... HTH Clemens --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
