All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Syn <john3909@gmail.com>
To: Mark Brown <broonie@kernel.org>, Lars-Peter Clausen <lars@metafoo.de>
Cc: <linux-iio@vger.kernel.org>, Matt Flax <flatmax@flatmax.org>
Subject: Re: DMA sampling and IIO
Date: Fri, 07 Feb 2014 14:19:59 -0800	[thread overview]
Message-ID: <CF1A99B5.1996C%john3909@gmail.com> (raw)
In-Reply-To: <20140207132058.GN32298@sirena.org.uk>


On 2/7/14, 5:20 AM, "Mark Brown" <broonie@kernel.org> wrote:

>On Thu, Feb 06, 2014 at 10:15:26PM +0100, Lars-Peter Clausen wrote:
>
>> I guess this is because it is the traditional area where I2S is used
>>and nobody
>> cared so far about using it somewhere else in the context of the Linux
>>kernel.
>> Not having to have a extra layer of abstraction in the middle between
>>ALSA/ASoC
>> and the I2S peripheral driver helped to keep things simple.
>
>Plus many of the uses actually found that the audio APIs were doing
>useful things for them anyway - the DMA bit is reasonably useful way of
>transferring continuous streams of data and nothing much cares if that
>data is actually audio or not so long as the application on top doesn't
>mind.
Hi Mark,

That is interesting. The ADE7878 transmits the measurements as 16
sequential measurements (Voltage A, Voltage B, Voltage C, Current A, etc)
and uses a frame to denote a new set of measurements. Can the audio API
cope with 16 channels and how do I prevent any modification (equalization,
etc) to the measurement data? Also, is it possible to break out these
measurements into separate buffers (Voltage A buffer, Voltage B buffer,
etc)? I guess I would access these measurement in the same way as an audio
application like aplay?

What I don¹t like about this solution is the possibility of missing
samples. In an audio app, this isn¹t so critical, but in my app this would
be a big problem. 

Regards,
John
>



  reply	other threads:[~2014-02-07 22:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-05 18:42 DMA sampling and IIO John Syn
2014-02-06  9:56 ` Lars-Peter Clausen
2014-02-06 19:43   ` John Syn
2014-02-06 21:15     ` Lars-Peter Clausen
2014-02-07 13:20       ` Mark Brown
2014-02-07 22:19         ` John Syn [this message]
2014-09-10 22:19         ` John Syn
2014-09-10 22:43         ` John Syn
2014-09-17 19:53           ` Mark Brown
2014-09-18  4:06             ` John Syn
2014-02-06 20:53   ` Alessandro Rubini
2014-02-06 21:02     ` Lars-Peter Clausen
2014-02-06 21:16       ` Alessandro Rubini
2014-02-06 21:38         ` Lars-Peter Clausen
2014-02-07 18:18           ` John Syn

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=CF1A99B5.1996C%john3909@gmail.com \
    --to=john3909@gmail.com \
    --cc=broonie@kernel.org \
    --cc=flatmax@flatmax.org \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    /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.