From: Vinod Koul <vinod.koul@intel.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: Jeeja KP <jeeja.kp@intel.com>,
alsa-devel@alsa-project.org, broonie@opensource.wolfsonmicro.com,
liam.r.girdwood@intel.com
Subject: Re: [PATCH] compress: add support for gapless playback
Date: Mon, 11 Feb 2013 05:41:47 -0800 [thread overview]
Message-ID: <20130211134147.GG3789@intel.com> (raw)
In-Reply-To: <s5htxpjotmp.wl%tiwai@suse.de>
On Mon, Feb 11, 2013 at 02:41:18PM +0100, Takashi Iwai wrote:
> At Mon, 11 Feb 2013 04:22:45 -0800,
> Vinod Koul wrote:
> >
> (snip)
> > --- a/include/uapi/sound/asound.h
> > +++ b/include/uapi/sound/asound.h
> > @@ -271,7 +271,9 @@ typedef int __bitwise snd_pcm_state_t;
> > #define SNDRV_PCM_STATE_PAUSED ((__force snd_pcm_state_t) 6) /* stream is paused */
> > #define SNDRV_PCM_STATE_SUSPENDED ((__force snd_pcm_state_t) 7) /* hardware is suspended */
> > #define SNDRV_PCM_STATE_DISCONNECTED ((__force snd_pcm_state_t) 8) /* hardware is disconnected */
> > -#define SNDRV_PCM_STATE_LAST SNDRV_PCM_STATE_DISCONNECTED
> > +#define SNDRV_PCM_STATE_NEXT_TRACK ((__force snd_pcm_state_t) 9) /* stream will move to next track */
>
> Isn't this better to be set as another flag instead of the trigger
> command? This changes the runtime->state, and it may make things
> complicated. For example, what happens if user triggers NEXT_TRACK,
> then PAUSE_PUSH and PAUSE_RELEASE?
hmmm, that makes sense. Also it would make things much easier on all the
transistions
>
> > +#define SNDRV_PCM_STATE_PARTIAL_DRAIN ((__force snd_pcm_state_t) 10) /* stream is draining partially */
> > +#define SNDRV_PCM_STATE_LAST SNDRV_PCM_STATE_PARTIAL_DRAIN
>
> Well, I'd hesitate to add this for PCM, since there is no counterpart
> for PCM (yet). Until then, let's avoid touching the PCM API
> definition but only compress API.
If we do above then we may not need this :)
> > +/**
> > + * struct snd_compr_metadata: compressed stream metadata
> > + * @count: number of keys
> > + * @keys: pointer to count keys
> > + */
> > +struct snd_compr_metadata {
> > + __u32 count;
> > + struct snd_compr_keyvalue *keys;
> > +};
>
> Do you really want that? Then you'll have to provide 32/64bit
> ioctl conversion functions as well. I wouldn't take that mess but let
> user repeat single key/value ioctls.
Ah, i forgot the damn pointer :-)
>
> Instead of relying completely on the driver side implementation, you
> can keep a metadata array in snd_compr_stream or snd_compr
> internally. Then the ioctl handler would be just like:
how do we decide the size of array and what if we have more params in future
> static int compr_stream_set_metadata(struct snd_compr_stream *stream, void __user * arg)
> {
> struct snd_compr_keyvalue kv;
>
> if (!stream->ops->set_metadata)
> return -ENXIO;
> if (copy_from_user(&kv, arg, sizeof(kv)))
> return -EFAULT;
> if (kv > SNDRV_COMPRESS_METADATA_LAST)
> return -EINVAL;
> stream->metadata[kv.key] = kv.value;
> return stream->ops->set_metadata(stream);
> }
And when do we clear this? metadata for gapless, though a same stream session
gets updated for every track.
Right now I am inlcined to put a single value, and be done with it or update
older structs with bunch of padding for future use :)
>
> Of course, this assumes that stream->metadata[] is initialized at each
> open properly.
Yes and it cant be cleared later for next track, perhpas we clear it when we get
NEXT_TRACK signalled from user space?
--
~Vinod
next prev parent reply other threads:[~2013-02-11 14:06 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-11 12:22 [PATCH] compress: add support for gapless playback Vinod Koul
2013-02-11 13:41 ` Takashi Iwai
2013-02-11 13:41 ` Vinod Koul [this message]
2013-02-11 14:38 ` Takashi Iwai
2013-02-11 14:55 ` Vinod Koul
2013-02-11 15:30 ` Takashi Iwai
-- strict thread matches above, loose matches on Subject: below --
2013-02-12 18:31 Vinod Koul
2013-02-13 6:23 ` Takashi Iwai
2013-02-13 6:35 ` Vinod Koul
2013-02-13 7:37 ` Takashi Iwai
2013-02-13 11:34 ` Mark Brown
2013-02-13 13:39 ` Vinod Koul
2013-02-13 16:00 Vinod Koul
2013-02-13 16:40 ` Takashi Iwai
2013-02-13 17:03 ` Vinod Koul
2013-02-13 17:15 ` Takashi Iwai
2013-02-13 17:21 ` Vinod Koul
2013-02-14 8:42 Vinod Koul
2013-02-14 9:13 ` Takashi Iwai
2013-02-14 9:32 ` Vinod Koul
2013-02-14 9:45 ` Takashi Iwai
2013-02-14 11:06 ` Vinod Koul
2013-02-14 11:22 Vinod Koul
2013-02-14 11:31 ` Takashi Iwai
2013-02-14 13:37 ` Vinod Koul
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=20130211134147.GG3789@intel.com \
--to=vinod.koul@intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=jeeja.kp@intel.com \
--cc=liam.r.girdwood@intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).