Fix adjust volume invalid in using soft volume for hfp

[xiaoyao888888]

When using soft volume, the sco volume cannot be adjusted, while it is normal in a2dp mode, so rename --a2dp-volume to --native-volume, and both a2dp/sco profiles can use it.

[arkq]

So in your case scenario you would like to have software volume by default for A2DP and for HFP/HSP ? Because currently BlueALSA uses hardware volume (it simply forwards volume requests to connected BT device) by default for HFP (because it is a feature covered by very early standard of HSP, and it works reliably as far as I know), and software volume for A2DP by default. The A2DP is software by default because it was not reliably in the past (due to bugs in BlueZ). But maybe in the future I will change it to "hardware" by default as well, because everything works fine with recent versions of BlueZ (I do not remember now in which BlueZ version the bug was fixed). Anyway the software volume can be selected with alsamixer or with bluealsa-cli.

[borine]

which BlueZ version the bug was fixed

There have been a number of issues that have affected AVRCP volume control in Bluez, but as afar as I know the last of them was fixed in BlueZ release 5.65. Certainly that version now works well for me.

Anyway the software volume can be selected with alsamixer or with bluealsa-cli.

But, IMHO, that is not sufficient when using bluealsa-aplay to build a sink. When building a sink using a system where 100% volume is unaccaptably loud (in my case I am using a RPi IQaudio DigiAmp) I like to use the sound card volume control to set the maximum volume, and then use a software volume control to attenuate the actual volume within that limit. So when using bluealsa-aplay with A2DP it is very convenient that sofware volume is used by default. I do not use SCO on that system, but if I did then I would loose this built-in software volume control and be forced to introduce an ALSA Softvol plugin. So in principle I think there is a genuine use-case for a bluealsa option to select softvol for SCO. I'm not convinced that it should be merged into the same option as A2DP though. Perhaps a new option --sco-volume ? I'm not sure, but its worth having a discussion about this. Perhaps a new option for bluealsa-aplay to select softvol rather than using the bluealsa server for this?

[arkq]

Perhaps a new option for bluealsa-aplay to select softvol rather than using the bluealsa server for this?

Yes, I think that such approach will be better (since your use case is with bluealsa-aplay). So, my proposition is to change A2DP do native by default, remove the --a2dp-volume and introduce mechanism which will select volume type for opened PCM when using bluealsa-aplay. However, I'm not sure about the user experience in case when someone will select software volume via bluealsa-aplay command line option, and later the volume will be change by some other application (e.g. alsamixer or bluealsa-cli)...

[borine]

the user experience in case when someone will select software volume via bluealsa-aplay command line option, and later the volume will be change by some other application

Hmm, yes that would have to be thought through carefully. Perhaps if properly documented in the manual page, then a "user beware" policy would be sufficient. I would like to know more about the specific use-case of @xiaoyao888888 (and any other interested parties) to help formulate a useful specification for this.

[xiaoyao888888]

Thank you all for your responses. My scenario involves having multiple audio input sources in the system, such as Bluetooth, music players, and more. We have virtualized a sound card to mix all the audio and send it to it. For Bluetooth, there isn't an actual hardware sound card, so we hope to adjust the volume using software.

[arkq]

My scenario involves having multiple audio input sources in the system, such as Bluetooth, music players

The scenario seems to be similar with the @borine's one. Are you using bluealsa-aplay in your setup too or maybe you are using ALSA PCM interface?

[xiaoyao888888]

Use ALSA PCM interface and also bluealsa-aplay for testing.

[arkq]

Use ALSA PCM interface and also bluealsa-aplay for testing.

When using ALSA PCM, there is a special option SOFTVOL which can be used to change software volume for opened PCM. Try something like this:
bluealsa:00:00:00:00:00:00,PROFILE=SCO,SOFTVOL=on when opening BlueALSA PCM.

[xiaoyao888888]

Try something like this: bluealsa:00:00:00:00:00:00,PROFILE=SCO,SOFTVOL=on when opening BlueALSA PCM.
It's working, but bluealsa-aplay is not.

[borine]

While I agree with you that giving bluealsa-aplay the ability to select software volume control for SCO is a useful suggestion, there may be a temporary workaround if there is a "real" soundcard attached to the system. That workaround is to use the ALSA softvol plugin. That plugin requires that there must be at least one card on the system, but it can control streams that do not use the card; so for example it could control the volume of the BlueALSA SCO stream that is sent to your virtual device. Here is an example: it assumes that your virtual device is called default; you should substitute the real PCM name of your device:

pcm.software-volume {
	type softvol
	resolution 2
	control {
		name "Softvol Playback Switch"
		card 0
	}
	slave.pcm {
		type softvol
		slave.pcm "default" # substitute the name of your virtual device PCM here
		control {
			name "Softvol Playback Volume"
			card 0
		}
	}
}

Start bluealsa-aplay with:

bluealsa-aplay --profile-sco --mixer-device=hw:0 --mixer-name=Softvol --pcm=software-volume  

Now bluealsa-aplay will pass-through the SCO volume setting to the Softvol plugin which will reduce the volume of the stream before sending it to your PCM device.

[arkq]

To automatically change volume mode to software when using bluealsa-aplay, please use new feature implemented in #664 (available in master branch now):

bluealsa-aplay --profile-sco --volume=software

[xiaoyao888888]

Thanks a lot, I will try new method.