Echoaudio driver, hint request

Echoaudio driver, hint request

[Giuliano Pochini]

My driver currently registers two pcm devices: pmc#0 for analog channels and
pcm#1 for digital channels. Though the DSP interface does not make that
distinction: for example the Gina24 has 2 analog and 8 digital input
channels and they are numbered 16..25. It's also possible to use a substream
made of all 10 channels at the same time.

The question is: what's better, the current approach of keeping analog and
digital channels on different pcm devices (quite messy at driver level), or
should I put them toghether and write a proper .alsarc file, so the user can
choose digital channels by name instead of by index ?



--
Giuliano.


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: Echoaudio driver, hint request

[Takashi Iwai]

At Mon, 8 Nov 2004 22:46:37 +0100,
Giuliano Pochini wrote:
> 
> My driver currently registers two pcm devices: pmc#0 for analog channels and
> pcm#1 for digital channels. Though the DSP interface does not make that
> distinction: for example the Gina24 has 2 analog and 8 digital input
> channels and they are numbered 16..25. It's also possible to use a substream
> made of all 10 channels at the same time.
> 
> The question is: what's better, the current approach of keeping analog and
> digital channels on different pcm devices (quite messy at driver level), or
> should I put them toghether and write a proper .alsarc file, so the user can
> choose digital channels by name instead of by index ?

It's diffituly to tell which is definitely better.

When someone wants to use OSS emulation for digital, it'd be nicer to
have a distinct device, so that it may work with the kernel OSS
emulation route.  OTOH, from the ALSA perspective, it's no problem to
have one stream with all channels.

So, the question is the difficulty of coding.  If the code wouldn't be
too complicated, the separate devices are easier and more
understandable for users.  If the code matters, choose the one stream
type like ice1712.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: Echoaudio driver, hint request

[Giuliano Pochini]

On Fri, 12 Nov 2004 11:21:37 +0100
Takashi Iwai <tiwai@suse.de> wrote:

> > My driver currently registers two pcm devices: pmc#0 for analog channels and
> > pcm#1 for digital channels. Though the DSP interface does not make that
> > distinction: for example the Gina24 has 2 analog and 8 digital input
> > channels and they are numbered 16..25. It's also possible to use a substream
> > made of all 10 channels at the same time.
> >
> > The question is: what's better, the current approach of keeping analog and
> > digital channels on different pcm devices (quite messy at driver level), or
> > should I put them toghether and write a proper .alsarc file, so the user can
> > choose digital channels by name instead of by index ?
>
> It's diffituly to tell which is definitely better.
>
> When someone wants to use OSS emulation for digital, it'd be nicer to
> have a distinct device, so that it may work with the kernel OSS
> emulation route.  OTOH, from the ALSA perspective, it's no problem to
> have one stream with all channels.
>
> So, the question is the difficulty of coding.  If the code wouldn't be
> too complicated, the separate devices are easier and more
> understandable for users.  If the code matters, choose the one stream
> type like ice1712.

No, it's not difficult. The driver uses separated devices since the first
release. It's a bit ugly, though. There are two couples of almost identical
pcm_open() functions and a couple of nested ifdef's. Btw, I'll keep the
current solution because it appears cleaner at user level.


--
Giuliano.


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8