Hi Pavel, Thanks for the reference to your previous discussion and the patches. They were super helpful. As you can see from my reply to Takashi, I'm proposing adding a convert_s32 method that doesn't impose dependency on a HW FPU on alsa-lib. The convert_s32 method would operate on an array of int32's. >From the point of view of the plugin developer, the change from convert_s16 to convert_s32 is pretty trivial. The plugins that I personally care about operate internally with floats. The plugin would remain responsible for converting between int32 and float. I agree that a libsoxr plugin would be great. Getting higher quality real-time resampling is my ultimate goal :) Thanks, Flavio -----Original Message----- From: Pavel Hofman <pavel.hofman@xxxxxxxxxxx> Sent: Wednesday, April 4, 2018 11:17 PM To: Flavio Protasio Ribeiro <flaviopr@xxxxxxxxxxxxx>; alsa-devel@xxxxxxxxxxxxxxxx Subject: Re: Conversion to int16_t and resolution loss with rate converter plugins Dne 5.4.2018 v 05:05 Flavio Protasio Ribeiro napsal(a): > Hi Folks, > > > > The libsamplerate and speex rate converter plugins only implement the > convert_s16 callback from snd_pcm_rate_ops_t. This has ALSA convert > the buffer to int16_t before handing it over to the plugin for > resampling. On devices with more than 16 effective bits, this implies > words gets truncated and bits are lost. > > > > Specifically for libsamplerate, the resampling is internally > implemented with floats, so truncating to 16 bits does not offer a > computational benefit. > > > > I get why only convert_s16 is implemented for plugins that aren't part > of the main alsa-lib package. The more generic convert callback comes > with the burden having the plugin support conversion from/to any of > the ALSA data types (or alternatively, having the plugin source > include plugin_ops.h and its dependencies). So here's what I > propose: replace convert_s16 with a convert_s32 callback which uses > int32_t instead of int16_t. This would preserve all bits from the > device and keep the plugin interface simple. Of course this means > plugins have to be updated to use convert_s32 and rebuilt. > > Hi, Many years ago I tried to extend the rate API to float, the native formats of libsamplerate and speex. I go stuck on float support of all platforms, perhaps you can get something from the discussion and patches. https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailman.alsa-project.org%2Fpipermail%2Falsa-devel%2F2011-June%2F041059.html&data=02%7C01%7Cflaviopr%40microsoft.com%7C1a39272ef41948b9e0e508d59abce88d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636585058520946316&sdata=y3iBvFGetAKtrkVO%2FUlHUUHSKpXSyko8pJme6NSlpQA%3D&reserved=0 https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailman.alsa-project.org%2Fpipermail%2Falsa-devel%2F2011-July%2F041503.html&data=02%7C01%7Cflaviopr%40microsoft.com%7C1a39272ef41948b9e0e508d59abce88d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636585058520946316&sdata=4%2F%2BIryERoT4btWN%2FGzYQmLH2Q86IPGr7odNuSAxJIVM%3D&reserved=0 If we succeed in adding >16 bit API to the rate plugin, perhaps supporting libsoxr would be the next step which would bring great value (performance vs. CPU load) to alsa-lib. Unfortunately that is not just about conversion, there are other quirks to iron out... Anyway, thanks a lot and good luck to your very useful endeavour. Best regards, Pavel. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
