2009-03-07, 05:28
I still don't know if I get the question. Are you asking if there will be navigational sound while a video is playing, and, further, will that sound come out of all 5.1 channels, or are you asking something else?
2009-03-07, 12:16
Yeah, as far as I get it he's asking for what you say.
I would love for some developer to chime in on the channel mappings thing. I crave for the smoothvideo branch...
I would love for some developer to chime in on the channel mappings thing. I crave for the smoothvideo branch...
2009-03-07, 20:16
I guess I honestly have no answer. I typically turn off as many navigational sounds as I can, because I find them irritating. I wasn't even aware there was a nav. sound issue during playback.
I'm assuming the issue is that no sounds are played when digital passthrough is selected? If this is that case, I would anticipate that nav. sounds would be identical to however they sound when passthrough is unselected and regular 2-channel analog is chosen.
Of course, being a guy who is just interested and who has absolutely no coding experience, I can say that I don't actually know the answer.
I'm assuming the issue is that no sounds are played when digital passthrough is selected? If this is that case, I would anticipate that nav. sounds would be identical to however they sound when passthrough is unselected and regular 2-channel analog is chosen.
Of course, being a guy who is just interested and who has absolutely no coding experience, I can say that I don't actually know the answer.
2009-03-08, 00:34
OK. As the guy who is developing on the master-audio branch, let me see if I can answer the questions asked, as well as provide some info about the direction of the effort.
First things first, the reason master-audio is a branch is because it is a work in progress. The architecture, API, and functionality are changing constantly, and the final feature-set has not been completely decided. What this means is that there are very few hard lines around what the framework will or will not do once the design stabilizes. Please bear this in mind as discussions continue, and be sure you are up to date on new commit activity before asking questions. Also, take a look at the Architecture Document if you have not. It is currently very high-level, but can certainly serve as a jumping-off point for discussion.
As for some of the questions asked previously, here is what I have to say on those:
@ashlar: I certainly agree that allowing for proper alignment of audio channels between formats and platforms is not, in and of itself, a good reason to revamp the audio code in XBMC, and I can assure that it had very little to do with my decision to develop the framework. It is, however, one of the problems that will be solved when all is said and done. I understand your interest in having the channel-mapping issue resolved, but ask that you be patient. The case is not that there is no interest in fixing the problem with the mappings, we simply would prefer not to spend time on code that will shortly be replaced by the framework. If you would like to submit a patch to trac that resolves the problem in the current architecture, I would be happy to take a look at it and commit it to the tree if it makes sense. Also, to your later comment, AC3Filter IS a complete DSP Chain, even if the name does not give that impression. I suggest that you take a look at the code for it (as I have) as a reference for how involved channel/codec management can be.
@Hitcher: The availablilty of Nav Sounds has a lot to do with the output encoding being used by the primary content, as well as the downstream sound system configuration. There is currently an option in the GUI to enable/disable Nav Sounds during playback. The effect of this setting varies by OS. In MasterAudio, nav sounds will be piped into their own 'virtual channel' and mixed into the final output stream. This should be possible for any of the output encoding formats employed by the framework. For passthrough streams it will not be possible to mix in the Nav Sounds, as that would require manipulation of the encoded stream (which would defeat the purpose of the passthrough). This is not to say, however, that all multichannel streams will be handled as passthrough. Users will have the ability to ask the system to 'leave the audio streams alone' for various formats, eliminating any possibility of degradation within XBMC. It is easy to get mixed up in the terms 'passthrough', 'digital', 'multichannel', etc. Keep in mind that 'digital' really only comes into play for encoded (AC3, DTS, etc..) streams and streams with > 2 channels. I haven't dug into the Linux rendering code too much yet, but I would wager that in all other cases, the 'analog' and 'digital' output settings in XBMC should behave similarly.
natethomas: Thank you for being an advocate and for your very good answers to other users' questions. When I believe there is enough new functionality to test and the build is somewhat reliable, I would be happy to make it available to you for testing. That being said, there is still a ways to go before it provides any real benefit over the existing system.
Moving along (for those that have not nodded off yet), I started this effort in response to the growing number of audio configuration/performance/compatibility problems and bugs being encountered by users. The audio code for XBMC is currently very decentralized, which makes the addition of new functionality difficult, and creates problems when trying to provide consistent behavior across inconsistent platforms. As new input formats and output hardware become available, limitations in the current design begin to surface. As a result, I decided to start development of a core audio subsystem for XBMC. For those that may be concerned about the impact to the robustness of XBMC, I offer this: Performance, Reliability, and Usability are foremost in my thinking and design, and the new framework will not force you to enable any features that appreciably increase the amount of processing performed by the software.
I have broken the project into 3 phases. Phase I seeks to develop the framework or 'container' in which all of the new functionality will be housed and update both of the existing players to use it. The phase will be considered complete when all of the current audio features supported by XBMC operate properly through the new API.
Phase II will focus on implementing new or missing functionality that addresses the most common user problems or feature requests. It will include channel re-mapping, basic format conversion, downmixing, upmixing, and several other new introductions. A lot of this work will involve moving decision points and processing out of the players and codecs and into the framework. It will be during this time that the changes to the software will begin to be visible to users.
Phase III is all about flexibility and features. After the core design has been completed and critical updates have been made, I will turn my attention to all of the new possibilities that will be offered by the framework. The decision to enable or disable these feature will be totally up to the user and will allow individuals to 'dial in' the configuration that best balances performance and functionality for them. I am going to refrain from suggesting what some of these features may look like (because it would come back to haunt me), but I assure you, many things are possible and I am looking forward to using them myself.
I hope this post addresses some of the questions and concerns of those who are interested. Feel free to keep the (constructive and on-topic) comments coming.
-C
First things first, the reason master-audio is a branch is because it is a work in progress. The architecture, API, and functionality are changing constantly, and the final feature-set has not been completely decided. What this means is that there are very few hard lines around what the framework will or will not do once the design stabilizes. Please bear this in mind as discussions continue, and be sure you are up to date on new commit activity before asking questions. Also, take a look at the Architecture Document if you have not. It is currently very high-level, but can certainly serve as a jumping-off point for discussion.
As for some of the questions asked previously, here is what I have to say on those:
@ashlar: I certainly agree that allowing for proper alignment of audio channels between formats and platforms is not, in and of itself, a good reason to revamp the audio code in XBMC, and I can assure that it had very little to do with my decision to develop the framework. It is, however, one of the problems that will be solved when all is said and done. I understand your interest in having the channel-mapping issue resolved, but ask that you be patient. The case is not that there is no interest in fixing the problem with the mappings, we simply would prefer not to spend time on code that will shortly be replaced by the framework. If you would like to submit a patch to trac that resolves the problem in the current architecture, I would be happy to take a look at it and commit it to the tree if it makes sense. Also, to your later comment, AC3Filter IS a complete DSP Chain, even if the name does not give that impression. I suggest that you take a look at the code for it (as I have) as a reference for how involved channel/codec management can be.
@Hitcher: The availablilty of Nav Sounds has a lot to do with the output encoding being used by the primary content, as well as the downstream sound system configuration. There is currently an option in the GUI to enable/disable Nav Sounds during playback. The effect of this setting varies by OS. In MasterAudio, nav sounds will be piped into their own 'virtual channel' and mixed into the final output stream. This should be possible for any of the output encoding formats employed by the framework. For passthrough streams it will not be possible to mix in the Nav Sounds, as that would require manipulation of the encoded stream (which would defeat the purpose of the passthrough). This is not to say, however, that all multichannel streams will be handled as passthrough. Users will have the ability to ask the system to 'leave the audio streams alone' for various formats, eliminating any possibility of degradation within XBMC. It is easy to get mixed up in the terms 'passthrough', 'digital', 'multichannel', etc. Keep in mind that 'digital' really only comes into play for encoded (AC3, DTS, etc..) streams and streams with > 2 channels. I haven't dug into the Linux rendering code too much yet, but I would wager that in all other cases, the 'analog' and 'digital' output settings in XBMC should behave similarly.
natethomas: Thank you for being an advocate and for your very good answers to other users' questions. When I believe there is enough new functionality to test and the build is somewhat reliable, I would be happy to make it available to you for testing. That being said, there is still a ways to go before it provides any real benefit over the existing system.
Moving along (for those that have not nodded off yet), I started this effort in response to the growing number of audio configuration/performance/compatibility problems and bugs being encountered by users. The audio code for XBMC is currently very decentralized, which makes the addition of new functionality difficult, and creates problems when trying to provide consistent behavior across inconsistent platforms. As new input formats and output hardware become available, limitations in the current design begin to surface. As a result, I decided to start development of a core audio subsystem for XBMC. For those that may be concerned about the impact to the robustness of XBMC, I offer this: Performance, Reliability, and Usability are foremost in my thinking and design, and the new framework will not force you to enable any features that appreciably increase the amount of processing performed by the software.
I have broken the project into 3 phases. Phase I seeks to develop the framework or 'container' in which all of the new functionality will be housed and update both of the existing players to use it. The phase will be considered complete when all of the current audio features supported by XBMC operate properly through the new API.
Phase II will focus on implementing new or missing functionality that addresses the most common user problems or feature requests. It will include channel re-mapping, basic format conversion, downmixing, upmixing, and several other new introductions. A lot of this work will involve moving decision points and processing out of the players and codecs and into the framework. It will be during this time that the changes to the software will begin to be visible to users.
Phase III is all about flexibility and features. After the core design has been completed and critical updates have been made, I will turn my attention to all of the new possibilities that will be offered by the framework. The decision to enable or disable these feature will be totally up to the user and will allow individuals to 'dial in' the configuration that best balances performance and functionality for them. I am going to refrain from suggesting what some of these features may look like (because it would come back to haunt me), but I assure you, many things are possible and I am looking forward to using them myself.
I hope this post addresses some of the questions and concerns of those who are interested. Feel free to keep the (constructive and on-topic) comments coming.
-C
2009-03-13, 16:10
If anyone is interested in the code, here is a link with the lastest commits to the master-audio branch.
http://trac.xbmc.org/changeset/18460
http://trac.xbmc.org/changeset/18460
2009-03-20, 11:12
Could anyone estimate time for this type of DSP chain development.... June, July or?
// M
// M
2009-03-20, 18:29
I'd guess we could probably estimate that, given the amount we are paying phi multiplied by effort/(work x hours), and further given the fact that we are in fact not paying phi anything at all, it will take anywhere from one day to infinite.
2009-05-15, 01:14
Out of curiosity, does anyone know if the CoreAudio work is related to the MasterAudio work, or is it a separate thing exclusive to OSX?
http://trac.xbmc.org/changeset/20274
http://trac.xbmc.org/changeset/20274
2009-05-15, 01:16
2009-05-15, 04:54
not related, however, now that I am mostly done with CoreAudio, I am going back to work on masteraudio 
I hope to get things moving along shortly.
I hope to get things moving along shortly.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
2010-01-21, 16:46
Just wondering if there's any update on how far along the master audio branch is?
Thanks,
Harry
Thanks,
Harry
2010-01-21, 18:43
I think it's been mentioned that phi2039 had stepped back for the moment. On the other hand it was mentioned as a temporary thing.
2010-01-22, 08:47
Still a temporary thing. Patience is a virtue.
