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

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

[Bach, Andrea]

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?

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

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

[Clemens Ladisch]

Bach, Andrea wrote:
> how can I change the size that is provided inside the „transfer“-
> callback of an external PCM plugin?

You cannot.

ALSA assumes that there is a ring buffer that has the configured buffer
size, and that when N frames are reported as available, any number of
frames between 1 and N can be read/written.

> 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

Handling less bytes than requested would imply that an error occured.

You could add your own buffer to keep any remaining frames of the
128-frame chunk until the next transfer call.


Regards,
Clemens
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

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

[Clemens Ladisch]

Bach, Andrea wrote:
> Ok, what about the output buffer?

"Output" from which point of view?  Playback or capture?

> When just 960 bytes are ready to be returned but I have to return 1000 bytes?

In theory, this is an underrun.

You could wait until the next 40 bytes are available.


Regards,
Clemens

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

[Clemens Ladisch]

Bach, Andrea wrote:
> how can I wait inside the transfer callback until the next bytes are available...

That depends on where you get the bytes from.


Regards,
Clemens

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

[Clemens Ladisch]

I mean, what is that thing that you're interfacing ALSA with?
Obviously, it somehow generates samples, but how exactly?


Regards,
Clemens

Bach, Andrea wrote:
> Mmh - I get them from the buffer argument of the transfer callback of the PCM external plugin.
> I do not have a second source... maybe I missed the "main thing" so is there an example of a PCM external plugin I can look at?
>
> Thank you
> Andrea
>
>> how can I wait inside the transfer callback until the next bytes are available...
>
> That depends on where you get the bytes from.
>
>
> Regards,
> Clemens
> 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

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

[Clemens Ladisch]

Bach, Andrea wrote:
> What I tried is to copy the buffer I get in chunks of a 64 bytes into
> an intermediate buffer for processing and whenever I processed
> 64 bytes I copied the result to the output buffer .... but what to do
> with the remaining 40 bytes...

Leave them in the intermediate buffer, and handle them later when you've
got 24 more bytes.

> and what to return in the output buffer when the remaining bytes could
> not be processed??

Delay the entire chain by 64 bytes, i.e., insert 64 byte at the start of
the stream.  Then you always have too many bytes instead of too few
bytes, and those can be handled with the intermediate buffer.


Regards,
Clemens

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

[Fernando Rodriguez]

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.

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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

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

[Fernando Rodriguez]

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