Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Presets preloading does not destinguish between speakers and jack output #1051

Closed
lakotamm opened this issue Jul 28, 2021 · 41 comments
Closed

Comments

@lakotamm
Copy link

lakotamm commented Jul 28, 2021

Hello, I would like to report an issue with presets reloading. I am not able to switch profiles automatically when I plug in/unplug my headphones. Easyeffects sees only one output device, no matter whether I use headphones or inbuilt speakers.

This is the same error as #918. Everything works fine with Pulseeffects version 4.8 and pulseaudio.

OS: Manjaro Gnome,
Kernel: 5.12
easyeffects: 6.0.3
pipewire: 1:0.3.32-1

Screenshot from 2021-07-28 12-38-46
Screenshot from 2021-07-28 12-39-01

@wwmm
Copy link
Owner

wwmm commented Jul 28, 2021

PipeWire and Pulseaudio handle headphones in a different way. So comparing them won't help much. I was expecting the hardware profile field to change when the headphone is plugged. I wonder if PipeWire is handling this device differently or we are not seeing the notification about the port change.

Kill the current instance easyeffects -q and restart it in debug mode G_MESSAGES_DEBUG=easyeffects easyeffects. After that plug and remove the headphone. Al save the output of pw-dump with and without the headphone.

@lakotamm
Copy link
Author

lakotamm commented Jul 28, 2021

Here are the outputs:
Headphones.txt
No headphones.txt

There seem to be relevant differences on lines 1844, 1865, 1988-2049. From what I see, the inbuilt and jack microphones are effected as well (there is also only a single device for them).

Let me know if there is anything else I can do to help fix the issue.

@wwmm
Copy link
Owner

wwmm commented Jul 29, 2021

I did not have time yet to investigate the pw-dump output but in easyeffects logs I see

device alsa_card.pci-0000_00_1f.3 has changed profile to: output:analog-stereo+input:analog-stereo

So at least one profile change we are seeing. But once you remove the headphone another line like that should come when going back to the previous hardware profile. Strange... Could it be that under the hoods Headphones - Built-in audio and Speakers - Built-in audio are associated to the same hardware profile analog-stereo+input:analog-stereo? That would break all of our autoloading logic. But at least on my desktop headphones and speakers are associated to different hardware profiles.

@wwmm
Copy link
Owner

wwmm commented Jul 29, 2021

At this moment what I do is trying to get from PipeWire the current hardware profile. Maybe I am doing this wrong. Maybe PipeWire is giving the same profile as answer for speakers and headphones. What does Pavucontrol show in its Output Devices and Configuration tabs with and without the headphone?

@lakotamm
Copy link
Author

lakotamm commented Jul 29, 2021

What does Pavucontrol show in its Output Devices and Configuration tabs with and without the headphone?

Headphones:
Screenshot from 2021-07-29 22-33-09
Speakers (I had the sound muted)
Screenshot from 2021-07-29 22-33-28
The configuration is the same no matter whether the headphones are inserted.
Screenshot from 2021-07-29 22-33-38

@lakotamm
Copy link
Author

lakotamm commented Jul 29, 2021

Could it be that under the hoods Headphones - Built-in audio and Speakers - Built-in audio are associated to the same hardware profile analog-stereo+input:analog-stereo? That would break all of our autoloading logic. But at least on my desktop headphones and speakers are associated to different hardware profiles.

I am not quite sure about this (I have zero experience with Linux audio), but if I correctly understand the pw-dump, the Profile parameter output:analog-stereo+input:analog-stereo (line 1773 ) stays the same no matter whether the headphones are connected or disconnected. Instead, there are changes under the EnumRoute and Route parameters.

EnumRoute parameter changes the availability for analog-input-internal-mic and analog-input-mic (1797 - 1836) + analog-output-speaker and analog-output-headphones (line 1840-1865).

Route parameter correctly identifies which Output and Input is being used. (line 1986-2057)

So in my case, the Route parameter could be used to correctly autoload.

@lakotamm
Copy link
Author

lakotamm commented Sep 6, 2021

Hi again @wwmm , I just wanted to ask whether there is any update about this issue. I am asking because I am getting the same issue on another laptop, so it does not seem to be an isolated case.

Thanks!

@wwmm
Copy link
Owner

wwmm commented Sep 7, 2021

Hi! I did not have time yet. Once my vacation was over there were tons of things to do at my work. I will try to take a look at this again tomorrow.

At this moment we are using SPA_PARAM_PROFILE to identify the device mode. But based on what we have seen your hardware does not change the profile name when plugging or unplugging the headphones. With lucky we can solve this by using SPA_PARAM_Route instead.

@wwmm
Copy link
Owner

wwmm commented Sep 7, 2021

@lakotamm I have updated the master branch with some changes that should fix this issue. It took more work than I was expecting but we are now using device routes instead of profiles to to the preset autoloading. Try to use the Arch package from AUR. It should be possible to use it on Manjaro.

@Digitalone1 if you have headphones try to do some tests too. This is one more of those situations where the hardware I have does not show any problem. Both the current implementation as well as the old one works. So it will be good to have other people testing. At least to see if the new approach did not bring new problems.

@Digitalone1
Copy link
Contributor

@Digitalone1 if you have headphones try to do some tests too. This is one more of those situations where the hardware I have does not show any problem. Both the current implementation as well as the old one works. So it will be good to have other people testing. At least to see if the new approach did not bring new problems.

Unfortunately it's partially working on my system.

I always found the autoloading profiles UI a bit confusing. The problem is that if I have the speakers and the headphones, I should see two entries in output devices while there's only one instead.

Don't know in English, but in Italian I see now the same label for second and third row: Profile. Maybe the second should be Hardware Profile.

Once I saved the profile for speakers, I see analog-output-speaker. When I save the profile for headphones I see analog-output-headphones.

They overwrite each other, so if I save the one for headphones, I get it when I plug in the headphones, but removing them does not restore the one I wanted and previously set for the speakers. And the analogous case happens when I save the preset for speakers.

@wwmm
Copy link
Owner

wwmm commented Sep 7, 2021

The problem is that if I have the speakers and the headphones, I should see two entries in output devices while there's only one instead.

I did not understand. If you have only one soundcard there will be only one entry in the output devices list. When a headphone is plugged the card profile or route changes. But the device is still the same.

but in Italian I see now the same label for second and third row: Profile.

Strange. The last line is the preset and the first two the device and the device route name. They should not be the same unless the preset was saved with the device or route name.

Once I saved the profile for speakers, I see analog-output-speaker. When I save the profile for headphones I see analog-output-headphones.

Ok. So your card is different from mine. I will have to combine the route and the device name when creating the file name. In my card they have different values.

@wwmm
Copy link
Owner

wwmm commented Sep 7, 2021

I will have to combine the route and the device name when creating the file name

Strange. That is already done. One of my autoloading profiles is named like

alsa_output.pci-0000_0f_00.4.analog-stereo:analog-output-headphones.json

What is inside your ~/.config/easyeffects/autoload/output/ folder?

@Digitalone1
Copy link
Contributor

Digitalone1 commented Sep 7, 2021

What is inside your ~/.config/easyeffects/autoload/output/ folder?

alsa_output.pci-0000_00_14.2.analog-stereo:analog-output-speaker.json

@wwmm
Copy link
Owner

wwmm commented Sep 7, 2021

alsa_output.pci-0000_00_14.2.analog-stereo:analog-output-speaker.json

When the headphones are plugged another file with a different name should have been created. Something like alsa_output.pci-0000_00_14.2.analog-stereo:analog-output-headphones.json

@wwmm
Copy link
Owner

wwmm commented Sep 7, 2021

I wonder if the solution I implemented before to allow profiles to be updated from the ui is removing all the previous profiles. I will take a look at it.

@Digitalone1
Copy link
Contributor

I did not understand. If you have only one soundcard there will be only one entry in the output devices list. When a headphone is plugged the card profile or route changes. But the device is still the same.

So If I don't have the headphones plugged in, I can't set a profile autoload for them. It's not comfortable, don't you think?

I know that is difficult to solve this issue, but if I have the speaker and the headphone for which I can set the profile, I expect to have them both in the drop down menu. At this moment I can set a profile for the headphones only after I plugged in them, and the profile for the speakers won't work.

Strange. The last line is the preset and the first two the device and the device route name. They should not be the same unless the preset was saved with the device or route name.

Maybe I have to update the translation.

@Digitalone1
Copy link
Contributor

When the headphones are plugged another file with a different name should have been created. Something like alsa_output.pci-0000_00_14.2.analog-stereo:analog-output-headphones.json

No, the previous is deleted and a new one is created.

@lakotamm
Copy link
Author

lakotamm commented Sep 7, 2021

@lakotamm I have updated the master branch with some changes that should fix this issue. It took more work than I was expecting but we are now using device routes instead of profiles to to the preset autoloading. Try to use the Arch package from AUR. It should be possible to use it on Manjaro.

@Digitalone1 if you have headphones try to do some tests too. This is one more of those situations where the hardware I have does not show any problem. Both the current implementation as well as the old one works. So it will be good to have other people testing. At least to see if the new approach did not bring new problems.

Thanks you very much for your time!

The good news:

  • easyeffects now clearly recognises different routes on the inputs and outputs
  • autoloading presets works!

The bad news:

  • whenever you try to create an autoloading combination for the same device (even if it is another route), the old combination gets deleted.

So trying to create a new autoloading preset for the same device (yet different route) removes the old one

(easyeffects:37105): easyeffects-DEBUG: 22:25:46.444: presets_manager: removed autoload: /home/manjaro/.config/easyeffects/autoload/output/alsa_output.pci-0000_00_1f.3.analog-stereo:analog-output-headphones.json
(easyeffects:37105): easyeffects-DEBUG: 22:25:46.444: presets_manager: added autoload preset file: /home/manjaro/.config/easyeffects/autoload/output/alsa_output.pci-0000_00_1f.3.analog-stereo:analog-output-speaker.json

Screenshot from 2021-09-07 22-28-48
As in this screenshot, it is possible to have only one preset, the old one always gets deleted.

Just FYI here is a log of connecting and disconnecting headphones (with only one preset -for speakers -enabled):

(easyeffects:37105): easyeffects-DEBUG: 22:33:51.179: application: device alsa_card.pci-0000_00_1f.3 has changed its output route to: analog-output-headphones
(easyeffects:37105): easyeffects-DEBUG: 22:33:51.750: application: device alsa_card.pci-0000_00_1f.3 has changed its input route to: analog-input-mic
(easyeffects:37105): easyeffects-DEBUG: 22:33:53.641: application: device alsa_card.pci-0000_00_1f.3 has changed its input route to: analog-input-internal-mic
(easyeffects:37105): easyeffects-DEBUG: 22:33:53.642: application: device alsa_card.pci-0000_00_1f.3 has changed its output route to: analog-output-speaker
(easyeffects:37105): easyeffects-DEBUG: 22:33:53.642: presets_manager: autoloading preset Speakers for device alsa_output.pci-0000_00_1f.3.analog-stereo
(easyeffects:37105): easyeffects-DEBUG: 22:33:53.642: presets_manager: loaded preset: /home/manjaro/.config/easyeffects/output/Speakers.json

@wwmm
Copy link
Owner

wwmm commented Sep 7, 2021

I wonder if the solution I implemented before to allow profiles to be updated from the ui is removing all the previous profiles. I will take a look at it.

That is the problem. I will have to think about another way to update profiles from the ui.

So If I don't have the headphones plugged in, I can't set a profile autoload for them. It's not comfortable, don't you think?

I see your point but trying to show in the ui profiles that are not active can make things way more complicated. Depending on the hardware there is a fair amount of possible combinations and not necessarily the user will know which one will actually work.

For example when I am not using a headphone my sound card automatically switches to its optical port. The output device in this case is named alsa_output.pci-0000_0f_00.4.iec958-stereo and the corresponding output route is iec958-stereo-output. If I plug a microphone in my front panel jack now I have available an input device named alsa_input.pci-0000_0f_00.4.analog-stereo associated to the route analog-input-front-mic.

Now imagine I plug a headphone. The optical port is not used anymore and the iec958 is replaced by an analog device alsa_output.pci-0000_0f_00.4.analog-stereo associated to the route analog-output-headphones. Totally different from what I had before.

I did not even consider in the example above the fact I also have a hdmi card. If we follow the "good path" where we show comboboxes with all the possible devices we also have to take into account that not all sound cards will support the same routes. My monitor's hdmi card does not have jacks for headphones. So it makes no sense to show this value in its route combobox.

It is not like it can not be done. We could query PipeWire about all the possible profiles for each of the available soundcards. The problem is that the code complexity involved escalates quickly. Creating a profile to the current available device and route is way easier. And the user does not have to know which combinations can actually work in his/her current setup. For example my card supports surround profiles and they will be in PipeWire's list. But I do not have these channels in my speakers or headphones.

@lakotamm
Copy link
Author

lakotamm commented Sep 7, 2021

I see your point but trying to show in the ui profiles that are not active can make things way more complicated.

I am perfectly fine with the way it is now (having to plug a device to create a preload for it) - no need to over-complicate it.

IMHO it would be nice to see the currently active "route". But that is not critical.

Fixing this bug should be the last bit to make easyeffects usable on laptops:
#1051 (comment)

@wwmm
Copy link
Owner

wwmm commented Sep 7, 2021

Master branch updated again. Now we check the device name and the route value. So it should not overwrite all the previous profiles anymore. I think it should work now. But for the reasons I explained in my last post I can not test this. When I plug a headphone my card goes from a digital to an analogical device with a different name.

@lakotamm
Copy link
Author

lakotamm commented Sep 7, 2021

It works for me! Thank you very much for your time!

@wwmm
Copy link
Owner

wwmm commented Sep 7, 2021

Ok! Good to know this was finally fixed.

@Digitalone1
Copy link
Contributor

Just tested on my system. It's working too me too. Thank you @wwmm.

@wwmm
Copy link
Owner

wwmm commented Sep 7, 2021

Ok. Let's close this issue :-)

@wwmm wwmm closed this as completed Sep 7, 2021
@mueslimak3r
Copy link

I think this is not resolved. I successfully created a preset autoload for my [Out] Speaker and it works. But when I plug in my headphones it does not unload the [Out] Speaker preset. The speakers and headphones are under a single device, like the OP.

The preset I'm using improves the laptop speakers' sound but shouldn't be applied while using headphones.

Should autoloading also autounload, or is that beyond the scope of the feature and I'm sol?

@Digitalone1
Copy link
Contributor

Hi @mueslimak3r. Are you using the latest master branch? Which files are under the autoload folder?

Post also a screenshot of the autoload tab if you can.

@mueslimak3r
Copy link

Hi @mueslimak3r. Are you using the latest master branch? Which files are under the autoload folder?

Post also a screenshot of the autoload tab if you can.

easyeffects-issue

@Digitalone1
Copy link
Contributor

I understand the choice to not allow more than one preset autoloaded per device

This is not true. With the latest changes you can do it. I'm afraid you are not using the latest master branch. Test easyeffects-git from AUR if you're on Arch. You should be able to create a preset autoload for speakers and another one for headphones, then they will be loaded on switch.

@lakotamm
Copy link
Author

lakotamm commented Sep 12, 2021

Should autoloading also autounload, or is that beyond the scope of the feature and I'm sol?

You do not automatically autounload, instead, you load another preset (which can be empty).

The way I do it:

  1. create 1 preset for headphones (with no filters) and 1 preset for speakers (with an equalizer in my case)
  2. with headphones unplugged, create preset autoload for speakers
  3. plug in headphones and created preset autoload for headphones

But again, this is possible only if you are using the latest version from master. I can confirm that self-compiled flatpak (manually modified to refer to the latest commit) works as well.

@mueslimak3r
Copy link

mueslimak3r commented Sep 12, 2021

I am (and was) using easyeffects-git from the AUR, verified up to date
I can confirm that having a separate autoloaded presets for the headphones and speakers routes does work, but only when I restart easyeffects.

(I named the empty preset 'none')

When I just unplug and plug back in the headphones it registers the change but does not load the presets
easyeffects-3

easyeffects-5

@mueslimak3r
Copy link

and here's when I restart it with the headphones unplugged
easyeffects-4

@Digitalone1
Copy link
Contributor

I think the problem is Pipewire changing your route to [In] Mic1, so EasyEffects can't load the preset for [Out] Headphones. Can you disable the microphone on your headphones just for a temporary workaround?

@wwmm
Copy link
Owner

wwmm commented Sep 12, 2021

But when I plug in my headphones it does not unload the [Out] Speaker preset.

That is right. You have to create a profile that will load another preset when another device becomes EasyEffects output device.

The code that is printing the changed route notification is this one

pm->device_output_route_changed.connect([&](DeviceInfo device) {
. If we see the new route but the preset is not applied one of the checks done after the message must be failing. But for now I do not see how this could be happening. I think we will need more debug messages to know which of the checks are failing.

@wwmm wwmm reopened this Sep 12, 2021
@wwmm
Copy link
Owner

wwmm commented Sep 12, 2021

I have updated the master branch with more debug messages. @mueslimak3r recompile your AUR package. Let's see if something new is shown in the logs.

@mueslimak3r
Copy link

mueslimak3r commented Sep 12, 2021

I think the problem is Pipewire changing your route to [In] Mic1, so EasyEffects can't load the preset for [Out] Headphones. Can you disable the microphone on your headphones just for a temporary workaround?

I'm not sure how to disable just a microphone route. It looks like my laptop has just one sound card. Is there a way to do this in pipewire?

soundhardware

easyeffects6

@wwmm
Copy link
Owner

wwmm commented Sep 12, 2021

So this is the problem

output autoloading: the target node name does not match the output device name

I have the feeling this is going to be tough to handle. PipeWire may be sending the signal about the route change before actually sending the signal about the device change. And as a result the check for the correct device id fails

if (node.device_id == device.id && node.media_class == "Audio/Sink") {

This is the only thing that comes to my mind now.

@Digitalone1
Copy link
Contributor

To be sure, try to print also the node id and the media class on the log.

@mueslimak3r
Copy link

To be sure, try to print also the node id and the media class on the log.

Gimme a shout if/when you need more logs (this time as a file). It looks like there's no new commits so I assume that's not a request for more logs from me.

@wwmm
Copy link
Owner

wwmm commented Sep 14, 2021

Gimme a shout if/when you need more logs (this time as a file). It looks like there's no new commits so I assume that's not a request for more logs from me.

Run pw-dump before and after plugging your headphone. I would like to see what PipeWire is doing with your devices when it detects your headphones.

@wwmm
Copy link
Owner

wwmm commented Jun 23, 2022

I think that the latest changes in EasyEffects 6.2.6 will fix this issue. If not then it is probably better to open a new one with new logs.

@wwmm wwmm closed this as completed Jun 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants