[PATCH 12/13] loopback: Validate the rate parameter

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 18.12.2015 08:45, Alexander E. Patrakov wrote:
> 18.12.2015 11:47, Georg Chini wrote:
>> On 18.12.2015 06:49, Tanu Kaskinen wrote:
>>>
>>>
>>> Making pa_sample_rate_valid() accept values above PA_RATE_MAX isn't
>>> very nice, but I can see how it's better than the current behaviour,
>>> which probably can cause the daemon to crash. Alexander mentioned in
>>> IRC that he'd prefer doing the adaptive resampling inside module-
>>> loopback rather than using pa_sink_input_set_rate(), and this change
>>> demonstrates one good reason for that. I'm not asking you to implement
>>> that change, but it certainly would be nice.
>>>
>>> -- 
>>> Tanu
>> Yes, doing it inside the module would really be a good idea. The
>> main issue my controller is fighting against are the systematic
>> errors introduced by changing the rate of the sink input. When
>> you change the rate, the next latency report has an extremely
>> high error.
>> Can you point me to some code that implements resampling
>> so that I have an example of what to do?
>
> Look at the ffmpeg resampler inside PulseAudio tree, it's the simplest 
> possible one. But I'd say that it's pointless to look at the code 
> without understanding the math behind all of that, so please look at 
> these links, too:
>
> https://en.wikipedia.org/wiki/Sinc_filter
> https://ccrma.stanford.edu/~jos/resample/resample.pdf
>
I would first use the existing resamplers before trying to implement my own.
So I was rather referring to the framework used in pulseaudio when using
existing resamplers. If I ever write a specific resampler for the 
loopback module
it could be integrated into the normal framework.



[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux