All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Clemens Ladisch" <cladisch@fastmail.net>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org, Lennart Poettering <mznyfn@0pointer.de>
Subject: Re: Channel mapping
Date: Thu, 22 Nov 2007 09:55:27 +0100	[thread overview]
Message-ID: <1195721727.28149.1222698051@webmail.messagingengine.com> (raw)
In-Reply-To: <s5h8x4rwqy1.wl%tiwai@suse.de>

Takashi Iwai wrote:
> Clemens Ladisch wrote:
> > Jaroslav Kysela wrote:
> > > We can also encode PCM device / subdevice numbers to data structure. But
> > > I think that best way is to extend channel_info PCM ioctl (create new 
> > > version and emulate old one - it should be quite easy to implement).
> > 
> > The channel_info ioctl returns only information about one channel.
> 
> OTOH, it's simple and easy to parse.  But, certainly TLV is more
> flexible for additional metadata.
> 
> > I think we should have a more flexible ioctl that also allows us to
> > describe the PCM device itself (such as volume controls that affect
> > all channels, or latency information).
> 
> Indeed, the mixer <-> PCM mapping can be useful.  For such
> information, the fixed size struct isn't suitable as multiple mixer
> elements correspond to a single PCM channel.

Okay, we already have the control's (sub)device fields for that ...

> BTW, what latency information do you have in mind?

How long it takes audio data to travel through the device, probably
DSP processing time + group delay.  I doubt that this value will be
known in many cases, or that applications will care.


It seems at the moment there isn't any information except the channel
order that is of interest to applications, so extended channel_info
would suffice for now.  I'm just concerned that there will be more
information in the future and that using TLV will prepare us for that.


Regards,
Clemens

      parent reply	other threads:[~2007-11-22  8:55 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-20  0:51 [lennart@poettering.net: Status of ALSA "simple" mixer interface] Lennart Poettering
2007-11-21 11:09 ` Takashi Iwai
2007-11-21 11:11 ` Takashi Iwai
2007-11-21 15:23   ` Clemens Ladisch
2007-11-25 19:56     ` The sense or non-sense of the device listing API (was: Status of ALSA "simple" mixer interface]) Lennart Poettering
2007-11-25 20:38       ` Jaroslav Kysela
2007-11-21 11:14 ` Mono device definition Takashi Iwai
2007-11-21 11:20 ` Analog-SPDIF dup Takashi Iwai
2007-11-21 11:22 ` Softvol controls Takashi Iwai
2007-11-29 23:28   ` Lennart Poettering
2007-11-29 23:46     ` John Utz
2007-11-30  0:08       ` Lennart Poettering
2007-11-30  0:34         ` John Utz
2007-11-30  8:59     ` Takashi Iwai
2007-12-04 15:42       ` Jaroslav Kysela
2007-12-13 10:39         ` Takashi Iwai
2007-12-22 22:54         ` Lennart Poettering
2007-12-23 10:21           ` Jaroslav Kysela
2007-12-22 22:48       ` Lennart Poettering
2007-11-21 11:40 ` Disable conversions Takashi Iwai
2007-11-21 14:29   ` Takashi Iwai
2007-11-21 15:16     ` Jaroslav Kysela
2007-11-21 14:51       ` Takashi Iwai
2007-11-25 20:41   ` Lennart Poettering
2007-11-26 15:55     ` Jaroslav Kysela
2007-12-22 22:37       ` Lennart Poettering
2007-11-21 11:42 ` Channel mapping Takashi Iwai
2007-11-21 15:17   ` Clemens Ladisch
2007-11-21 14:57     ` Takashi Iwai
2007-11-21 15:27     ` Jaroslav Kysela
2007-11-21 15:04       ` Takashi Iwai
2007-11-27 16:54         ` Takashi Iwai
2007-11-21 15:52       ` Clemens Ladisch
2007-11-21 15:36         ` Takashi Iwai
2007-11-21 18:37           ` Jaroslav Kysela
2007-11-22  9:17             ` Clemens Ladisch
2007-11-22  8:55           ` Clemens Ladisch [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1195721727.28149.1222698051@webmail.messagingengine.com \
    --to=cladisch@fastmail.net \
    --cc=alsa-devel@alsa-project.org \
    --cc=mznyfn@0pointer.de \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.