+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32)
+--- Forum: Kodi Application (https://forum.kodi.tv/forumdisplay.php?fid=93)
+--- Thread: Testing audio engine ActiveAE (/showthread.php?tid=170338)
RE: Testing audio engine ActiveAE - fritsch - 2014-05-15
See the AESink.h - you can incorporate any hw volume you would like ...
See for example my AESinkPULSE - it uses external, in that case stream volume and syncs with xbmc.
RE: Testing audio engine ActiveAE - MGA1500 - 2014-05-21
(2014-05-15, 11:10)fritsch Wrote: See the AESink.h - you can incorporate any hw volume you would like ...
See for example my AESinkPULSE - it uses external, in that case stream volume and syncs with xbmc.
Hi Fritsch,
I have gone through the entire audio engine structure and code and am pretty sure how I can achieve what I want; make xbmc believe the sink has hardware volume control while sending the actual volume through a custom channel to the hardware. To start with the latter, the new event server will trigger part of my own addon by using the OnVolumeChange() event. This is a part that anyone can use for sending volume control commands to their amplifiers through serial links, ethernet etc.
Fixing the volume setting is a matter of -if I am correct- simply reporting back to the audio engine through the class CActiveAE::CActiveAE() that m_sinkHasVolume = true instead of false. The structure of ActiveAE is such that it will then simply not apply volume control to the data channel. In the pulse audio sink the volume setting is sent to the pulse audio mixer. In my case this will be taken care of by code in my addon.
Now the question is how -from team XBMC PoV- I can best implement my 'feature' to maximally benefit other users that have similar requests (I have found 5-10, not too much though) and be included in the XBMC branch. The way of forcing ALSA in a pulse audio system is through an environment variable. I have also thought about advancedsettings.xml but that is abandonded in Gotham for good reasons. Making a copy of the default ALSA sink with as only difference and added "HasVolume() {return true}" seems a very ineffective way of implementing a small difference.
What is your opinion how I should proceed? Modifying the code directly and rebuilding XBMC/Openelec is no problem but this would not really be in good open source spirit I feel ;-)
Looking forward to your reply so I can start implementing and see how I can give it back to the community by using github.
Regards,
RE: Testing audio engine ActiveAE - fritsch - 2014-05-21
There are only two methods. One to return true :-) and one to actually set the volume.
We can then later think of e.g. Expert Setting or something else. Remember - if iwe return false above - everything is as it is now. So you cannot really break something by just adding a new method.
RE: Testing audio engine ActiveAE - MGA1500 - 2014-05-21
(2014-05-21, 17:01)fritsch Wrote: There are only two methods. One to return true :-) and one to actually set the volume.
We can then later think of e.g. Expert Setting or something else. Remember - if iwe return false above - everything is as it is now. So you cannot really break something by just adding a new method.
Thanks for confirming ;-) But the question about what your preference would be for my implementation? Using an envoriment variable like "AE_SINK_VOL=fixed" or not attempting to change anything in the main branch and making my own copy and keep tis solution local? Not sure if you understood my real question beside how to do it...
Thx!
RE: Testing audio engine ActiveAE - fritsch - 2014-05-22
Get the functionality done first - then we can see how the integration can be done. As said - it's only "call the SetVolume method or not"
RE: Testing audio engine ActiveAE - FernetMenta - 2014-05-22
Quote: make xbmc believe the sink has hardware volume control while sending the actual volume through a custom channel to the hardware
If you implement it as this sentence suggests, it will be nothing more than a hack. "make believe" means that existing design is abused and shortcuts are implemented which taint the architecture. A sink is at a lower layer and its thread runs at higher priority. Here we don't want any custom channel hooked into.
RE: Testing audio engine ActiveAE - cg110 - 2014-05-24
Hi,
I've done a few bits of tidy up in AE, and wondered if someone could take a look before I generate the PR:
https://github.com/cg110/xbmc/commit/17f9822d4138ca11107bf6091581af09a87b3296
Mainly it's just initializing some variables, and switching some funcs to pass by ref rather than copying things. Compiled succeeded on windows and linux.
One item I wasn't sure on, in ActiveAEBuffer.h, the internal_format for CSoundPacket looks to be unused? Shall I just delete it, or have I missed it's usage?
Thanks
RE: Testing audio engine ActiveAE - fritsch - 2014-05-24
I checked the PA Changes, they are fine. Other AE parts are currently heavily reworked: https://github.com/FernetMenta/xbmc/commits/audio
RE: Testing audio engine ActiveAE - MGA1500 - 2014-05-24
(2014-05-22, 16:02)FernetMenta Wrote:Quote: make xbmc believe the sink has hardware volume control while sending the actual volume through a custom channel to the hardware
If you implement it as this sentence suggests, it will be nothing more than a hack. "make believe" means that existing design is abused and shortcuts are implemented which taint the architecture. A sink is at a lower layer and its thread runs at higher priority. Here we don't want any custom channel hooked into.
Hi FernetMenta,
agree; architectures are to be respected to be structured. I have to admit that I 'hacked' it for the moment to see if Hasvolume() {return true;} has the proper effect ie. leave the pcm samples unaffected. An alternative volume control channel 'downstream' (like in the pulse audio sink) should be sent from the sink instead (eg to ALSA ctl channel).
However, for cases where a custom volume control is desired (full scale all the way to amplifier and have this amplifier do the volume control over serial commands, ethernet etc) what would be a proper, xbmc-architecture-respecting way where users can 'hook in' their specific control?
In my opinion there are conflicting interests; an add-on would be the easiest and non-main-branch-intruding way of implementing the control channel but doing it in an add-on (you cannot come 'higher' in the architecture...) is what you are opposing. Doing it in the sink (at the right low level) would require a different sink for all different implementations and will pollute the code base?
Your post exactly illustrates why I posted my question as to know your preference from an architecture PoV...
Regards, MGA
PS. An alternative (learnt it from muffinman) is to add an ALSA sink that uses ALSA softvol. An out-of-XBMC volume channel can be configured through a custom .asoundrc file and a piece of code that presents itself as a volume control to alsa and can implement anything. I rather have a easier-to-implement structure in XBMC though
RE: Testing audio engine ActiveAE - cg110 - 2014-05-25
(2014-05-24, 15:28)fritsch Wrote: I checked the PA Changes, they are fine. Other AE parts are currently heavily reworked: https://github.com/FernetMenta/xbmc/commits/audio
In which case perhaps it's best left till when that's done, rather than confuse merges etc. The changes are really just minor tidy up.
RE: Testing audio engine ActiveAE - FernetMenta - 2014-05-25
(2014-05-24, 16:21)MGA1500 Wrote: In my opinion there are conflicting interests; an add-on would be the easiest and non-main-branch-intruding way of implementing the control channel but doing it in an add-on (you cannot come 'higher' in the architecture...) is what you are opposing
I am not opposed to doing this in an addon, I just don't want the addon to be hooked into the sink. In case such an addon becomes activated, set volume of AE to max and direct volume control to the addon. That would also work for passthrough audio.
RE: Testing audio engine ActiveAE - fritsch - 2014-05-25
(2014-05-25, 04:04)cg110 Wrote:(2014-05-24, 15:28)fritsch Wrote: I checked the PA Changes, they are fine. Other AE parts are currently heavily reworked: https://github.com/FernetMenta/xbmc/commits/audio
In which case perhaps it's best left till when that's done, rather than confuse merges etc. The changes are really just minor tidy up.
If you want, you can PR the two PA changes separately. They can go in as is.
RE: Testing audio engine ActiveAE - Muffinman - 2014-05-26
(2014-05-24, 16:21)MGA1500 Wrote: PS. An alternative (learnt it from muffinman) is to add an ALSA sink that uses ALSA softvol. An out-of-XBMC volume channel can be configured through a custom .asoundrc file and a piece of code that presents itself as a volume control to alsa and can implement anything.
This is not entirely correct.
The way I would propose to have some more control over volume in XBMC is to allow volume control in the ALSA sink to be done via a mixer device in ALSA instead of the internal volume control of XBMC. This requires a similar setup as is already there in the PULSE sink. So, this in no way requires an extra sink. It does require an expert user option in which the user can set the mixer device, mixer, and index to diverge from the default internal volume control. I think this is a clean and in some cases useful extension of the existing ALSA implementation.
For unidirectional volume control all it requires is the function SetVolume() to be set. To be bi-directional I think it requires an extra thread to keep track of changes happening at the ALSA end (unless there is someway to trigger such a synchronization at some time interval?).
This benefits those who have a soundcard with hardware volume control (increased sound quality) and allows one to have other applications to handle volume control*. This setup is also present in applications such as MPD and Shairport. However, whatever happens at this end is not of any relevance to XBMC, it shouldn't and doesn't care. All it does is sync volume with an ALSA device/mixer.
Kind regards, Maarten
*) I've created an app that syncs volume changes back and forth between in ALSA and RS232 (quite configurable so suitable for a broad range of amplifiers that carry a serial interface). All it requires is that the ALSA dummy soundcard is loaded (modprobe snd_dummy) and that applications such as XBMC allows setting the mixer device, mixer, and index. So, this is not as complicated as suggested above.
RE: Testing audio engine ActiveAE - fritsch - 2014-05-26
Increased sound quality? xbmc internally calculates with float, so applying volume is lossless.
RE: Testing audio engine ActiveAE - Muffinman - 2014-05-26
Well, with a software volume control (regardless of method), wouldn't you lose resolution?