At Thu, 17 Oct 2002 08:42:35 -0500, [EMAIL PROTECTED] wrote: > > On Thu, Oct 17, 2002 at 10:26:48AM +0200, Takashi Iwai wrote: > > ah, since 8000Hz 8 bit is not supported on this device. > > please use plughw instead of hw, that is, > > > > % aplay -Dplughw:1,0 foo.wav > > atrophy:~# aplay -Dplughw:1,0 foo.wav > Playing raw data 'foo.wav' : Unsigned 8 bit, Rate 8000 Hz, Mono > ALSA lib pcm_hw.c:428:(snd_pcm_hw_prepare) SNDRV_PCM_IOCTL_PREPARE failed: Invalid >argument > aplay: set_params:813: Unable to install hw params: > ACCESS: RW_INTERLEAVED > FORMAT: U8 > SUBFORMAT: STD > SAMPLE_BITS: 8 > FRAME_BITS: 8 > CHANNELS: 1 > RATE: 8000 > PERIOD_TIME: (124988 124989) > PERIOD_SIZE: (999 1000) > PERIOD_BYTES: (999 1000) > PERIODS: (4 5) > BUFFER_TIME: 500000 > BUFFER_SIZE: 4000 > BUFFER_BYTES: 4000 > TICK_TIME: 10000 > atrophy:~# > > I've tried an entire array of different wav's in different formats, > all with similar debugging output. > > I've also tried installing various modules and drivers in a vain and > blind attempt to just get it to play the stream. What "is supported" > natively by the driver? this is shown exactly in /proc/asound/card*/stream*. iirc, the 48000Hz 16bit 2ch is the only supported format on extigy. (there should be more, but they are likely not parsed correctly - see below.)
but anyway it's strange that the format above is not accepted by plughw. please check - whether the files mathing with native format are ok. - whether the file above with OSS emulation works (which converts inside the kernel). > > for the control (mixer) interface, no second zero, that is, use > > '-Dhw:1'. (btw, it's equitvalent "amixer -c 1"). > > Yes, I've been able to mix the thing properly now. Thanks. Uh, I'm > guessing the code is the best place to actually get a decent > description why this is? > > > > I compiled both controler modules and have tried using them > > > interchangably. Same result. There is no difference in the stream0 > > > file - checked with a diff. > > > > you can check this also via the output of 'lsusb -v'. > > Only differences were fairly cosmetic: > > atrophy:~/alsa# diff uhci usb-uhci > 15c15 > < iProduct 2 USB UHCI-alt Root Hub > --- > > iProduct 2 USB UHCI Root Hub > 50c50 > < Bus 001 Device 002: ID 041e:3000 Creative Labs > --- > > Bus 001 Device 005: ID 041e:3000 Creative Labs > > I had to disconnect my minihub and connect only the extigy by itself > in order to use the usb-uhci driver. I normally only use uhci, as I > need to use a usb mouse and the extigy, which requires a hub that > doesnt like usb-uhci. > > Given the output above, I'm probably doing something rather silly > again with regards to some kind of random compatibility issue. I am > still running the mixer with the debug hack you put in. i'm not sure what's going on there, but the lsusb output once you sent me contains much more supported formats. and i experienced that the similar phenomenon happened on other usb-audio devices - not the whole descriptors are parsed. the behavior might be changed if you reboot. sigh... i guess it's likely a bug of usb controller modules. Takashi ------------------------------------------------------- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
