swh / ladspa

The SWH Plugins package for the LADSPA plugin system
http://plugin.org.uk/
GNU General Public License v2.0
229 stars 52 forks source link

mbeq plugin outputs frying noise when I use 32 bit library #64

Open Monsterovich opened 5 years ago

Monsterovich commented 5 years ago

My .asoundrc: https://pastebin.com/MbQCCcr2

When I do "ALSA_PCM=equal LADSPA_PATH=/usr/lib/ladspa32 any_32_bit_program test.flac" or play sound in any 32 bit application I get very loud noise instead of sound.

This plugin works fine with 64 bit library.

Noise example recorded from my audio card: mbeq_test.ogg.zip

swh commented 5 years ago

I'm pretty sure this is a problem in ALSA. This codebase is very old, and hasn't hasn't changed in years.

Does it happen with other plugins, or just this one?

Monsterovich commented 5 years ago

Does it happen with other plugins, or just this one?

What plugin should I test and how?

swh commented 5 years ago

Any of them, z-1 is the simplest. http://plugin.org.uk/ladspa-swh/docs/ladspa-swh.html#tth_sEc2.113

Monsterovich commented 5 years ago

Any of them, z-1 is the simplest. http://plugin.org.uk/ladspa-swh/docs/ladspa-swh.html#tth_sEc2.113

I tried this plugin in both 32 bit and 64 bit architectures and it works fine in both as it should.

    plugins [
    {
        label vynil
        id 1905
    }
    ]
swh commented 5 years ago

Interesting - I can't think of any reasons why that would work and the other doesn't, they've both got filters in.

Monsterovich commented 5 years ago

I can't think of any reasons why that would work and the other doesn't

I can only think of platform differences that cause this problem. I also tested swh-plugins by doing chroot to pure 32 bit prefix and I have same noise here.

It's possible that this bug is caused by libfftw3f on 32 bit platform because afaik other plugins don't use it.

DaveBullet1050 commented 4 years ago

Bit of a dredge... but I am also getting EXACTLY the same noise/hiss/crackle as you are playing your ogg file.

it is strange - since aplay and mpg123 play fine directly to alsa configured alsaequal or direct LADSPA plug ins. This works for zm1, vynil and mbeq on my ArchlinuxARM system.

However - when i use mbeq under MPD (either via alsaequal or ladspa) - I am getting the noise you are.

This was working fine on my old ArchlinuxARM version - so I'm guessing a downstream package upgrade has broken things... I've tried "forcing" downgrades - everything works (until you really go into the bowels) - e.g. alsa-lib, fftw, gsm, yet the hiss from mbeq is there.

swh commented 4 years ago

That's very odd, it was originally built under a 32 bit system.

There's very few downstream dependencies of the plugin, and the filter is just implemented with compiled C expressions IIRC,

[edit: I was confusing it with something else]

DaveBullet1050 commented 4 years ago

Thanks for replying Steve... I am ignorant on what is needed to make sure 32-bit support is enabled. My guess is it's a "thunking" issue :) I know you mentioned the requirement in the README for this library, so will re-read and try to work out how I ensure i enable 32-bit support in FFTW3.

I have had no problem recompiling your plug-ins from XML source but that has made no difference (just incase some object dependency / version in my distribution was making a difference and it was a "linking issue") or somesuch).

Edit: Realise what I need to do for FFTW3 recompilation (the arm7a features may not be required / a problem.. so will retry without them if needed): ./configure --enable-float --enable-sse --enable-armv7a-cntvct --enable-armv7a-pmccntr

DaveBullet1050 commented 4 years ago

Well latest update - I recompiled FFTW3.3.8 (latest version) as well as using the old one on my old installation (v3.3.7) - no change. that is - either via alsaequal or ladspa "direct" - I can get all plugins working via mpg123 and aplay clients. MPD works with vinyl via LADSPA direct, or zm1, but hisses / crackles via LADSPA or alsaequal under MPD (same asound.conf). The funny thing is MPD works fine with alsaequal's 10 band EQ (in caps.so) under MPD.

A debug session in MPD is in order to see how it is opening alsa/ladspa

DaveBullet1050 commented 4 years ago

I resolved my issue.

I had to recompile mbeq without optimisation. i.e. CFLAGS = -O0

Any higher level (e.g. -O1, -O2, -O3) causes mbeq to play "static" via MPD even though the same higher optimised shared object plays fine under other players / hosts (aplay / mpg123).

The above has been a real pain in the neck to troubleshoot. but that was my problem.

I've got no idea why this is the case.

DaveBullet1050 commented 4 years ago

One other gotcha.... for some reason a change in possibly alsa 1.2.2+ or alsa-utils 1.2.2+ means a port descriptor length overflow occurs.

Edit mbeq_1197.xml and shorten the name as shown- i.e. remove the "(low shelving)" suffix.

            <port label="band_1" dir="input" type="control" hint="default_0">
                    <name>50Hz gain</name>
                    <range min="-70" max="+30"/>
            </port>

... and recompile

Otherwise you get an unhelpful "cannot load mixer controls: No such file or directory"

When loading the plugin via alsamixer

jerryr commented 3 years ago

I had the same problem and setting CFLAGS="-O0" fixed it for me too. I was getting the same scratchy sound and also noticed that it took several seconds for the plugin to initialize, during which one CPU core was stuck at 100%. There was also a loud scratchy noise immediately after initialization which caused my amplifier to reset due to clipping. All of these issues were solved by compiling with optimization disabled.