> 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? -- rncbc aka Rui Nuno Capela rncbc@xxxxxxxxx ------------------------------------------------------------------------- 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
