Re: alsa-lib: snd_device_name_hint() function

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 :)

> 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?

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.

- All alises are shown.  For example, I get both iec958 and
  spdif although they are identical.

- Similar problems are seen for sudrround* defintions.  They
  show all same texts.

- The most important one, default PCM, has no description at all. 

Since the apss may likely show only descriptions in the selection
list without the cryptic device name, the same description texts would
confuse users.  That's the reason why I insist the requirement of
hint description.

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.

Let's define the target first, what is needed and how it behaves...


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

[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux