Re: Question about the buffer length in the transfer callback of the PCM External Plugin

From: Fernando Rodriguez <cyklonite@gmail.com>
To: Alsa-devel@alsa-project.org
Subject: Re: Question about the buffer length in the transfer callback of the PCM External Plugin
Date: Mon, 31 Oct 2016 14:47:49 -0400	[thread overview]
Message-ID: <20161031184748.GB25567@navi.local> (raw)
In-Reply-To: <20161031181116.GA25567@navi.local>

On Mon, Oct 31, 2016 at 02:11:17PM -0400, Fernando Rodriguez wrote:
> On Mon, Oct 31, 2016 at 09:01:02AM +0000, Bach, Andrea wrote:
> > Hello,
> > 
> > how can I change the size that is provided inside the „transfer“-callback of an external PCM plugin?
> > 
> > Background:
> > I need to write a filter plugin and I have to use for processing a chunk size of power of two (32, 64, or 128 bytes … that’s because of the use of FFT). But I get inside the transfer callback a buffer of length 1000. That would be ok if I could just return let's say  960 bytes – but after some struggling I have some doubt about it because I got the impression that ALSA cannot change the bitrate inside such a plugin – the documentation states it could not change the sample rate – but actually how can I return less or more bytes – so maybe the bitrate should also be constant? Maybe I misunderstood the concepts of ALSA completely?
> > 
> 
> Yes.
> You're working with raw PCM data, so the bitrate (bits per second) is
> constant ((bit_depth/8) * samplerate * channels). The term usually
> refers to compressed audio streams.

Oops, that was in bytes. It's bitdepth * samplerate * channels.

> 
> I haven't done this but by looking at the definition for the transfer
> callback it looks pretty standard. It returns snd_pcm_sframes_t so I
> suppose you can write less than *size* frames and return what was
> actually written. It is signed so a negative value would indicate an
> error. So you'll probably have to buffer any leftovers and write them on
> the next call. That's not the same as changing the framerate because
> at the end of the pipeline alsa will take care of playing it at the
> right rate).
> 
> That should clear some of the confussion. You'll probably have to look
> at alsa-lib or some plugin's source code for more details.
> 
> 
> > Kind regards
> > 
> > Dr. A. Bach, Software-Entwicklung Simulatoren
> > DFS Deutsche Flugsicherung GmbH
> > Forschungszentrum
> > Am DFS-Campus 5
> > 63225 Langen
> > 06103-707-5709
> > 
> > DFS Deutsche Flugsicherung GmbH
> > Am DFS-Campus
> > D - 63225 Langen
> > 
> > Tel.: +49-(0)6103-707-0
> > 
> > Sitz der Gesellschaft: Langen/Hessen
> > Zuständiges Registergericht: AG Offenbach am Main, HRB 34977
> > Vorsitzende des Aufsichtsrats: Dr. Martina Hinricher
> > Geschäftsführer: Prof. Klaus-Dieter Scheurle (Vors.), Robert Schickling, Dr. Michael Hann
> > 
> > Internet: http://www.dfs.de
> > Public-Key der DFS: http://www.dfs.de/dfs/public_key.asc
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 
> -- 
> Fernando Rodriguez

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