At Wed, 14 Feb 2007 14:30:17 -0000 (WET), Rui Nuno Capela wrote: > > > > At Tue, 13 Feb 2007 21:01:35 +0000, > > Rui Nuno Capela wrote: > >> > >> Karsten Wiese wrote: > >> >> How about using snd_pcm_hw_params_get_channels_max() ? > >> >> At least on capture the US224 should give 2 and the US428 should give > >> 4 > >> >> as the maximum number of channels. > >> >> > >> >> It would be handful for me if the attached test program could be ran > >> >> against a US428, just for the records ;) > >> >> > >> >> On my US224 it gives: > >> >> > >> >> $ snd_hwdep_info hw:3 > >> >> ---hwdep--- > >> >> snd_hwdep_info_get_id (hw:3) = 'USX2Y Loader' > >> >> snd_hwdep_info_get_name (hw:3) = '/proc/bus/usb/001/004' > >> >> ---pcm (capture)--- > >> >> snd_pcm_hw_params_get_channels_min(hw:3) = 2 > >> >> snd_pcm_hw_params_get_channels_max(hw:3) = 2 > >> >> ---pcm (playback)--- > >> >> snd_pcm_hw_params_get_channels_min(hw:3) = 2 > >> >> snd_pcm_hw_params_get_channels_max(hw:3) = 2 > >> >> > >> >> Karsten? > >> > > >> > ./a.out hw:1 > >> > ---hwdep--- > >> > snd_hwdep_info_get_id (hw:1) = 'USX2Y Loader' > >> > snd_hwdep_info_get_name (hw:1) = '/proc/bus/usb/004/007' > >> > ---pcm (capture)--- > >> > snd_pcm_hw_params_get_channels_min(hw:1) = 2 > >> > snd_pcm_hw_params_get_channels_max(hw:1) = 2 > >> > ---pcm (playback)--- > >> > snd_pcm_hw_params_get_channels_min(hw:1) = 2 > >> > snd_pcm_hw_params_get_channels_max(hw:1) = 2 > >> > > >> > The 428's 4 capture channels are only visible to the raw-usb jack > >> thing. > >> > and this is only there for module param nrpacks=1..... > >> > > >> > What do you see in your /sys/bus/usb/devices/... ? > >> > (Not that I knew how to deduce the sysfs file from the hwdep->name) > >> > > >> > >> We're in trouble... there must be another way. What about the shm > >> accessed from us428control? Is there supposed to be some watermark or > >> something? Maybe even the number of fader-channels, who knoes? I'm > >> afraid only you Karsten can grok that ;) > > > > The easiest way would be to add a new hwdep ioctl in usx2y driver to > > return the USB ids, etc. Also, hardcoding the path /proc/xxx is wrong > > in the current driver code. It has to be fixed, too. > > You can still add an option to us248control to specify the device type > > for making it work with the old driver. > > > > Another way is to use libusb and look for the device with the given > > location. The merit of this is that you need no change in the kernel > > although the resultant code might be slightly more complicated. > > > > BTW, the new systems have usually /dev/bus/usb instead of > > /proc/bus/usb. But such path is really system-dependent, and > > shouldn't be embedded in the driver code. > > > > Hmmm... I'm coming up with some workaround... yes, I guess the easiest > solution is about adding a new command line option to us428control, > stating which model we're into, either us428 or us224; us428 would be the > default. > > This way, for it to work out-of-the-box, and for the US224 at least, one > should just change the respective udev rule, where I think the switch is > made based on the actual product-id on power-up. > > What you think? This is another way I thought of, too. How compatible between these two models? If running with a wrong option doesn't bring fatal errors like segfault, it'd be surely a good workaround. Of course, some consistency check in us428control would be nice to have. Takashi ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
