At Wed, 11 Oct 2006 16:12:21 +0200 (CEST), Jaroslav Kysela wrote: > > On Wed, 11 Oct 2006, Takashi Iwai wrote: > > > At Wed, 11 Oct 2006 13:45:53 +0200 (CEST), > > Jaroslav Kysela wrote: > > > > > > Hi, > > > > > > because no one objected against new snd_device_name_hint() > > > function prototype (see bellow for hg URL), I commited my implementation > > > to the hg repository. > > > > Hmm... a bit too early to commit to the public tree, I'm afraid. > > (People can't always answer in a day after a new post -- and I even > > didn't look at code/API closely yet.) > > But it's no big problem since it's alsa-lib not the kernel tree, we > > can play freely :) > > I would like to push patches as fast as possible in the development phase. > We can eventually revert them before 1.0.14 final. I understand it. In general, a personal HG tree would be more suitable for such a purpose... > > > http://hg.alsa-project.org/alsa-lib?cs=b4ac1aee3f07 > > > > > > Additions from last update: > > > > > > 1) add hint {} section to the device definition > > > hint.description "Description" > > > hint.device integer > > > hint.device_input integer > > > hint.device_output integer > > > 2) hint 0 - disable listing of this device definition > > > 3) show device name like: > > > > > > front:CARD=Intel,DEV=0|ALC880 Analog: Front speakers and multichannel output > > > > > > 4) notify available direction (if possible) in comment like > > > > > > spdif:CARD=Intel,DEV=0|ALC880 Digital {Playback}: IEC958 (S/PDIF) Output > > > > Isn't it better to split the device name and the description to > > separate strings? > > Maybe, but it does not matter. I chose one container rather than playing > with complex structures or defining group of indexes. Maybe. I'm not sure about this but should be more discussed. > > I see some problems in the descriptions shown via aplay -L: > > > > - The description doesn't include the hardware name. > > you get same description texts for all cards. > > Yes, it makes sense to add the card's longname and device number for fine > device identification into description. I will do. The device number is almost useless as a description, IMO. One doesn't care about device #4 but does for "SPDIF" device. (Though, your example below looks good enough.) > > - All alises are shown. For example, I get both iec958 and > > spdif although they are identical. > > Yes, but it's not easy. Probably, it should be fixed in configuration. Agreed. One of them should be suppressed. > > - Similar problems are seen for sudrround* defintions. They > > show all same texts. > > Configuration problem. How to be fixed? > > - The most important one, default PCM, has no description at all. > > I forget to mention that I defined hints only for HDA hardware. I'll add > configuration for other hardware soon. > > Here's output from my HDA machine: > > null > Discard all samples (playback) or generate zero samples (capture) > front:CARD=Intel,DEV=0 > ALC880 Analog: Front speakers and multichannel output > surround40:CARD=Intel,DEV=0 > ALC880 Analog: Front speakers and multichannel output > surround41:CARD=Intel,DEV=0 > ALC880 Analog: Front speakers and multichannel output > surround50:CARD=Intel,DEV=0 > ALC880 Analog: Front speakers and multichannel output > surround51:CARD=Intel,DEV=0 > ALC880 Analog: Front speakers and multichannel output > surround71:CARD=Intel,DEV=0 > ALC880 Analog: Front speakers and multichannel output > iec958:CARD=Intel,DEV=0 > ALC880 Digital {Playback}: IEC958 (S/PDIF) Output > spdif:CARD=Intel,DEV=0 > ALC880 Digital {Playback}: IEC958 (S/PDIF) Output > default:CARD=Intel > ALC880 Analog: Default dmix+softvol + dsnoop device The detailed implementation isn't needed to be shown here... > dmix:CARD=Intel > ALC880 Analog: Direct sample mixing device > dsnoop:CARD=Intel > ALC880 Analog: Direct sample snooping device dmix and dsnoop are confusing as well as hw and plughw. > > > My goal isn't for tools like aplay. It's fine to show all devices for > > aplay since it's a lowlevel program and should handle in a lowlelvel > > manner. But, for GUI programs that you can do everyhing only with > > mouse click without guess work, API should be designed to provide a > > good enough usability. So, obviously, that's the difference we see. > > I'm sorry, but a click maybe a wrong click. Well, if a user choose an item that he _understands_, then it cannot be a "wrong" click from design POV. > I agree that we need to > describe devices to be understandable for normal users, of course. Definitely. The descriptions and concentps are way too cryptic for normal users yet. For normal users, it doesn't matter what dmix, dnsoop or whatever underlies the selected device. A user wants to see only "what this item is for". > Also, I would like to reorder devices in alsa.conf (like move default > device as first etc.). Any objections? That sounds good. BTW, one missing thing is the capability of the listed devices. For example, if the SPDIF device supports only 32bit and iec958 doesn't include plug layer, most of apps cannot use it as it is. And, we cannot ask apps to add plug by itself. In one side, it makes sense to define spdif without plug (or linear) layer. On th other hand, it's not for normal apps. So, here is also another dilemma between usability and lowlevel-implementation. Takashi ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
