From: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: vinod.koul@intel.com, ckeepax@opensource.wolfsonmicro.com,
alsa-devel@alsa-project.org, elaurent@google.com
Subject: Re: [TINYCOMPRESS][PATCH 1/1] compress: no need to set metadata before calling next_track
Date: Mon, 3 Mar 2014 13:25:47 +0000 [thread overview]
Message-ID: <20140303132547.GA20710@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <530F62CA.6080002@linux.intel.com>
On Thu, Feb 27, 2014 at 10:07:38AM -0600, Pierre-Louis Bossart wrote:
> On 2/26/14 8:29 AM, Richard Fitzgerald wrote:
>> The metadata is mainly for MP3 gapless playback, since
>> the MP3 audio stream does not contain enough information
>> to enable gapless. Other audio formats do not necessarily
>> require any additional metadata so we should allow next_track
>> to be called without any metadata.
>
> Metadata is required for both MP3 and AAC gapless playback. Can you
> clarify what 'other formats' you are referring to? And rather than
> removing the check that makes sense for these popular formats, why not
> send metadata to set the # of samples to skip to zero?
> Thanks,
> -Pierre
>
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Any format, or any use-case, where we don't need to send metadata. I said "other formats do not
_necessarily_ require any additional metadata". I'm not saying that _no_ other format needs metadata,
just that it's not something that's always going to be mandatory. Also you shouldn't think only in
terms of gapless play, you can chain track together for other reasons than gapless (for example to
make best use of the DSP buffering and allow maximum host sleep time across multiple tracs) and still
want to be able to do partial drains to know when the DSP starts decoding the next track.
It would be possible to send a dummy metadata, but why send dummy ioctls to make the API work
when we could just remove the check that isn't needed?
Also there's no reason why the kernel should be enforcing this restriction - the core ALSA state
machine doesn't need the metadata so it should be left to the DSP driver and/or firmware to decide
whether metadata is mandatory in the current situation.
next prev parent reply other threads:[~2014-03-03 13:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-26 14:29 [TINYCOMPRESS][PATCH 1/1] compress: no need to set metadata before calling next_track Richard Fitzgerald
2014-02-27 16:07 ` Pierre-Louis Bossart
2014-03-03 13:25 ` Richard Fitzgerald [this message]
2014-03-03 14:57 ` Pierre-Louis Bossart
2014-03-03 16:36 ` Richard Fitzgerald
2014-03-03 19:40 ` Pierre-Louis Bossart
2014-03-06 10:32 ` Richard Fitzgerald
2014-03-07 14:32 ` Richard Fitzgerald
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=20140303132547.GA20710@opensource.wolfsonmicro.com \
--to=rf@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=ckeepax@opensource.wolfsonmicro.com \
--cc=elaurent@google.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=vinod.koul@intel.com \
/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