WIP: Extract platform dependent code out of Skill #76
Conversation
| # Instantiate the HAL emulator | ||
| self.platform = self.config_core['enclosure'].get('platform', 'unknown') | ||
| if self.platform in ALSA_PLATFORMS: | ||
| self.HAL = HALFactory.create('ALSA', self.settings) |
There was a problem hiding this comment.
Pardon the intrusion, especially for a kind of style comment, it's not very important, I'm kind of wondering why this doesn't read
`self.HAL = HALFactory.create(self.platform, self.settings)`
And let "create" decide what to return rather than needing to switch on platform here (given that it's a HAL).
There was a problem hiding this comment.
Or even self.HAL = HALFactory.create(self.config_core, self.settings)
There was a problem hiding this comment.
No intrusion at all - glad to have more eyes on it.
You're totally right here too - I'm thinking passing in the self.platform should be sufficient for now.
I expect that this will change when it moves to the real HAL service, as each HAL plugin will either select their audio output service or provide their own methods that meet a minimum spec.
|
Tip from sgee in chat: Just dropping it here to come back to. |
Description
Currently the Volume Skill has lots of ALSA specific code embedded in it. I took a stab at starting to extract out the platform dependent code. The intention is that this code will be moved to the Hardware Abstraction Layer (HAL) - formerly known as "enclosure" but there are way too many things that are "enclosures".
For the moment, I've created a little HAL "emulator" in the Skill that should only be interacted with via the bus. Once the real HAL interface is ready we should be able to delete the module from the Skill and the rest will continue to function as normal.
Interested in any thoughts on this approach before I bother going too far, so opening a work-in-progress PR.
Most recently raised in MycroftAI/enclosure-picroft#153
Type of PR
Testing
Documentation
Docstrings included
CLA