-
Notifications
You must be signed in to change notification settings - Fork 130
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
PA control enhancements #263
Conversation
…ed zone types, tested X10, xPL, xAP, object and wdio. xPL and xAP were only tested to send to the designated IP address - verified with netcat on target computer.
…ng cepstral swift for voice
…ze on arrow notation for parms.
…they were on before starting speech.
…oneous code comment.
…eaks more reliably in desired rooms, due to correcting a race condition.
Steve, same thing with this request too. Can you confirm its stabilty? Also, I suspect there is a conflict with the other speech commit that I just merged. If you merge master into this branch you can fix the conflicts. |
Conflicts: lib/read_table_A.pl
Wow, just saw this comment too... Yes, I feel it's stable, and I already merged without noticing your comment. LOL |
…ents, rather than the index of the last element. (index 0 = element 1)
Did a little housekeeping to make me more comfortable with a merge. Tests good on two machines. |
…multiple speaker out channels to be used as separate PA rooms.
Added Alsa support to allow different sound card channels to be PA rooms through amixer in Linux.
Updated PAObj and pa_control to allow for a mix of different zone types and added a new zone type of "object". You can now use an existing object as a PA zone or a member of a group if it accepts ON and OFF commands via set. I tested this by using an Insteon object.
This could be used to turn on a device or lamp while MH is speaking. Perhaps an animated head just for fun! More practically, an IOLINC could be used to turn on a remote speaker. Scenes should work as well.
The on thing that I'm not sure how to handle long term is the extra delay in turning things on when there are multiple devices to send commands to. There could be X10, Insteon, weeder and other devices that are all sent messages. The io device, amp or whatever should confirm that they're on before the audio is sent, or we may miss the first part if the PLM is busy. Either way, this is a step in the right direction.