On Thu, 06 Aug 2020 13:08:13 +0200, Vinod Koul wrote:
On 23-07-20, 22:33, Takashi Iwai wrote:
On Thu, 23 Jul 2020 17:56:12 +0200, Vinod Koul wrote:
On 23-07-20, 15:17, Takashi Iwai wrote:
On Thu, 23 Jul 2020 15:05:22 +0200, Vinod Koul wrote:
On 23-07-20, 14:38, Takashi Iwai wrote:
On Tue, 21 Jul 2020 19:00:01 +0200, Srinivas Kandagatla wrote: > > For gapless playback it is possible that each track can have different > codec profile with same decoder, for example we have WMA album, > we may have different tracks as WMA v9, WMA v10 and so on > Or if DSP's like QDSP have abililty to switch decoders on single stream > for each track, then this call could be used to set new codec parameters. > > Existing code does not allow to change this profile while doing gapless > playback. > > This patchset adds new SNDRV_COMPRESS_SET_CODEC_PARAMS IOCTL along with > flags in capablity structure to allow userspace to set this new > parameters required which switching codec profile, either for gapless > or cross fade usecase.
One idea that came up at the previous audio conference regarding this implementation was to just allow SET_PARAMS during the stream is running (only if the driver sets the capability) instead of introducing yet a new ioctl and an ops. Would it make sense?
That does sound good but only issue would be that we need to somehow mark/document that buffer info is useless and would be discarded, how do we do that?
Yes, the buffer and no_wake_mode can be ignored in the gapless re-setup. Is your concern only about the documentation? Or something else needs to be changed significantly? It's a new scheme in anyway, so the documentation update is required...
My concern is potential abuse of API down the road, if you feel it is okay, I am okay with the proposal
If this can be potentially dangerous, it shouldn't be used, of course. What kind of scenario could it be?
I can think of users trying to invoke this incorrectly, right now we would reject this.
Maybe, we can add checks like, if next_track is set and then copy the codec params only to prevent any misuse.
Do you think that would be okay?
Yes, it's the same condition check that was proposed for the new ioctl.
Takashi