All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
* Re: Alsa-devel Digest, Vol 40, Issue 58
@ 2010-06-13 10:47 Tobias Schneider
  0 siblings, 0 replies; only message in thread
From: Tobias Schneider @ 2010-06-13 10:47 UTC (permalink / raw
  To: alsa-devel



----- Ursprüngliche Nachricht -----
Von: alsa-devel-request@alsa-project.org
Gesendet: Sonntag, 13. Juni 2010 12:00
An: alsa-devel@alsa-project.org
Betreff: Alsa-devel Digest, Vol 40, Issue 58

Send Alsa-devel mailing list submissions to
	alsa-devel@alsa-project.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
or, via email, send a message with subject or body 'help' to
	alsa-devel-request@alsa-project.org

You can reach the person managing the list at
	alsa-devel-owner@alsa-project.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Alsa-devel digest..."


Today's Topics:

   1. Re: ALSA's jack reporting framework map to Android framework
      (Mark Brown)
   2. Re: [PATCH] ASoC: Remove unused header (Mark Brown)
   3. Re: Timing Info (Paul Dugas)


----------------------------------------------------------------------

Message: 1
Date: Sat, 12 Jun 2010 18:05:52 +0100
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
Subject: Re: [alsa-devel] ALSA's jack reporting framework map to
	Android framework
To: "Harsha, Priya" <priya.harsha@intel.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,	Mike
	Lockwood <lockwood@android.com>
Message-ID: <20100612170552.GA3110@sirena.org.uk>
Content-Type: text/plain; charset=us-ascii

On Sat, Jun 12, 2010 at 09:28:34AM +0530, Harsha, Priya wrote:

Please fix your MUA to word wrap your messages, it makes them more
legible and easier to reply to.

> The ALSA's jack reporting framework reports jacks at
> /dev/input/eventx. But the Android framework expects the jack reporting
> to be done in /sys/.../switch/h2w.

That ... is simply 'class' - the Android kernel includes a new sysfs
class for switches, CCing in Mike Lockwood who wrote it in case he's got
any input from the Android side.

> Any suggestions as to how  the ALSA's jack reporting framework to
> Android framework? Are there any audio  drivers that have mapped this?

The obvious thing to do here seems to be to update the Android framework
to be able to use the standard kernel interfaces.  I obviously can't
speak for Google but it seems like the sort of patch they'd be willing
to accept, especially if you retain the ability to use the non-standard
extensions that are currently being used.

I guess an alternative would be to have the Android kernels add an
adaptor in the input subsystem (for various reasons not all jack sense
goes through ALSA) so that input subsystem switches get represented via
the Android switch ABI, though that would increase the amount of out of
tree code that needs to be carried and so seems like the wrong direction
to be heading.


------------------------------

Message: 2
Date: Sat, 12 Jun 2010 18:07:15 +0100
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
Subject: Re: [alsa-devel] [PATCH] ASoC: Remove unused header
To: Liam Girdwood <lrg@slimlogic.co.uk>
Cc: Grant Likely <grant.likely@secretlab.ca>, Herb Peyerl
	<hpeyerl@beer.org>,	alsa-devel@alsa-project.org,
	linux-kernel@vger.kernel.org
Message-ID: <20100612170715.GB3110@sirena.org.uk>
Content-Type: text/plain; charset=us-ascii

On Fri, Jun 11, 2010 at 10:50:40AM +0100, Liam Girdwood wrote:
> On Thu, 2010-06-10 at 17:54 -0600, Grant Likely wrote:
> > The header contains an extern that isn't used by anything.  Remove.

> > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

> Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>

Applied, thanks.


------------------------------

Message: 3
Date: Sat, 12 Jun 2010 17:59:27 -0400
From: Paul Dugas <paul@dugasenterprises.com>
Subject: Re: [alsa-devel] Timing Info
To: alsa-devel@alsa-project.org
Message-ID:
	<AANLkTik3ycq3POxHRG_bc0jO-KByZVvirVJ-X9-bySY_@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

On Fri, Jun 11, 2010 at 6:00 PM, Paul Dugas <paul@dugasenterprises.com> wrote:
> I'm using snd_pcm_readi() to collect samples and am wondering if/how I
> can get accurate timestamps for them. ?Seems like the snd_pcm_status()
> gives me this info but I'm unclear on the specifics. ?Can someone
> point me toward the correct field in the status structure that I
> should be using and what sample that timestamp corresponds to?
>
> Does snd_pcm_status_get_tstamp() get me the timestamp for the first
> frame returned by the next snd_pcm_readi() call?

I know now get_tstamp() isn't what I'm looking for after reading some
prior postings and other web sites.  Can't seem to find a discussion
of timing in the ALSA docs themselves.  Maybe I'm being dense.

Looks like some processing of the trigger timestamp is what I need but
I'm not following the logic of "triggers" in the simple use of
snd_pcm_readi() that I've got.  Before the first readi() call, the
trigger time is 0.  The second time, it's pretty close to the wall
time for the first call.  Perhaps that's the timestamp of the first
sample of the first period I read and I need to add the period_time
each time?  Seems like that'd accrue error when recording over longer
periods of time (which my application does).

What's the "timestamp mode".  Does it generate a timestamp each
period?  How would I access that timestamp?

Thanks in advance for any assistance,

Paul


------------------------------

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel


End of Alsa-devel Digest, Vol 40, Issue 58
******************************************

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2010-06-13 10:48 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-06-13 10:47 Alsa-devel Digest, Vol 40, Issue 58 Tobias Schneider

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.