[DaveBlake]

My use of dual audio is similar to Gurabli. Audio output 1 goes to my hifi DAC (via USB), while output 2 is to the TV speakers via HDMI. My primary use is music, so I turn on my amp and often leave the TV off completely, using Kore app on an Android tablet as a remote control. If I do put the TV on (to do something the app interface does not support, check the guide, or programme my PVR etc.) I mute the TV sound. Conversely most of my video viewing is done with my amp off just using the TV speakers, but if I am watching a really good movie with a worthwhile soundtrack then I can turn on the hifi (and mute the TV). I never listen to both outputs at the same time.

This makes my htpc running Kodi my central entertainment system, and with DualAudio it is doing the job magnificently.

Yes, same here!

Could be interesting to know how other dual audio users use this variant. How many want simultaneous/synched output, how many just want to be able switch between devices easily? Of course they are just happily out there using it, and unlikely to be reading this thread!

Kodi is an open source project that means that a new feature does not need "official" interest to be implemented. Anyone can do it. But as we mentioned several times: we won't integrate code that is not done properly.

I think I have already mentioned the biggest flaw of this code here. You need to find a solution how to make a/v sync working for multiple audio devices. Feel free to ask questions, I am happy to help.

I totaly support maintaining coding standards, and did not mean any offence. Yes as an excellent opensource project anyone can submit code, however time pressures on monitors and the needs to maintain project integrity means that anything more than a small patch, no matter how well implemented, is unlikely to be embraced easily. I suspect a new contributor would have to earn some respect first too. I am not complaining, just being realistic. But hey, lets talk and see if we can move forward.

What I don't understand is your assertion that multiple audio output needs to be synched. Why? It obviously makes the solution harder, and current users of the dual audio (like myself) are happy without synching.

Next question, why does a "proper solution" have to support multiple output to more than two devices? Again if it is harder, surely having two is a good first step? In my case it would be sufficient too. Just how many users really want more?

Perhaps there is confusion over what this project is trying to do? I think the fundamental user requirement is to be able to send audio to both a TV (audio to the video device) and to another audio device, in such a way that you can switch easily (e.g. single button press) and instantaneously between them, but not necessarily listen to both at the same time. Switching audio output device needs to be controlable without having to turn on the TV (video device), so that if listening to the TV sound was the last use you don't need to turn on the TV to switch audio output to the other audio device.

Having the audio always come out of both outputs, and controlling which one you are listening to by using the devices themselves seems an efficient approach. It can be clearly stated that the sound is not synchronised.

I am still unclear what code is impacted by this unofficial patch, not saying I can do anything to contribute but I would love to know.

[gurabli]

DaveBlake, excellent summary, nothing to add from a users perspective.
Still wonder who and why would use both audio outputs at the same time. And if somebody wants to do this, as you said, should be clearly stated they are not in sync, as it is not the purpose of dual audio.
Contact DarkAngel regarding the code, I think he will be able to explain what is done and how.

[FernetMenta]

But hey, lets talk and see if we can move forward.

The fact that I respond in this thread states that I am open for discussion. I have pointed out the major flaws of this change multiple times and its been ignored.

no matter how well implemented, is unlikely to be embraced easily. I suspect a new contributor would have to earn some respect first too

Check out audio DSP or 3DLUT in the development section of the forum. Those authors talked to us and listened. Instead of ignoring the hints they followed the advice of the senior devs.

[DaveBlake]

I have pointed out the major flaws of this change multiple times and its been ignored.

Sorry but I am new to this, and although I have searched I have not been able to find pevious comments. Could you possibly summerise or maybe point me to the posts.

I genuinely do not understand why syncing is an issue with this project, I have not experienced any problems neither does Gurabli. Are you saying that the two audio engines get out of sync with each other? Please elaborate.

Check out audio DSP or 3DLUT in the development section of the forum. Those authors talked to us and listened. Instead of ignoring the hints they followed the advice of the senior devs.

OK will do. It is not obvious from the start who to talk to or where about what.

Edit: looked at those topics, don't recognise all the terms but pressume that I am meant to note the tone of posts not the tech content! If I have got off on the wrong foot then apologies, I really have no idea what have may gone before. I'm just an enthusiastic new user that needs the functionality this dual audio provides and so would like to see it become main stream.

From a user perspective this project seems to work fine. I really would like to know what the flaws are in the approach taken. The 26 pages of this thread and the 4k of posts from you are not easy to search, and so far I have failed to find where you point out the flaws in this project. Do help me out with some more hints.

[FernetMenta]

From a user perspective this project seems to work fine.

In your particular case it may work ok as long it stays in the happy path, that is i.e. no special error handling is required. From an architectural point of view, this code is a disaster. If Kodi were a building and we added this code, I promise you would stay away from that building as far as you can. Consider a tall building with 10 floors in the basement. Would you ever dare to create an 11th floor where the entire building puts its load on? Obviously not, right. If you were able to visualise this code here, you would see this architectural disaster. It just duplicates the entire audio engine and the interface to players.

Integrating such a code which violates almost every rule in software development would make Kodi unmaintainable. Do you want to see the project die in favour of a quick win of a single feature? This thread is really dead end. If someone want to implement this feature she/he needs to go back to drawing board and start from scratch.

[DaveBlake]

FernetMenta, I don't know anything about tall buildings etc., but I do know about software design having been in the industry for over 30 years and worked on large mission critical 24/7 systems with many contributors. I don't scare easily, I do understand how much work things can take, and most importantly I am interested enough to try and contribute.

The fact that I respond in this thread states that I am open for discussion.

Good, nice to have some help from a Kodi team member to understand what the problems are. Clearly you do not like the way this project has been implemented, but since it is the obvious starting point for anyone considering dual audio it really would help if you could explain what the flaws are. At least a link to where you have explained before would help.

Perhaps best start from the beginning.
Can we agree that there is a user requirement to be able to send audio to both a TV (audio to the video device) and to another audio device, in such a way that you can switch easily (e.g. single button press) and instantaneously between them, but not necessarily listen to both at the same time. Switching audio output device needs to be controlable without having to turn on the TV (video device), so that if listening to the TV sound was the last use you don't need to turn on the TV to switch audio output to the other audio device.

It seems from this long thread, and others that predate it, that this is a real user need. It is a fundamental need for me and Gurabli at least.

[FernetMenta]

Perhaps best start from the beginning.
Can we agree that there is a user requirement to be able to send audio to both a TV (audio to the video device) and to another audio device, in such a way that you can switch easily (e.g. single button press) and instantaneously between them, but not necessarily listen to both at the same time. Switching audio output device needs to be controlable without having to turn on the TV (video device), so that if listening to the TV sound was the last use you don't need to turn on the TV to switch audio output to the other audio device.

ok

but not necessarily listen to both at the same time

Requirements need to be unambiguously.

A architectural requirement is: no duplication of audio engine

[gurabli]

FernetMenta is THE developer, never came across with a dev of so much knowledge and still full of so much willingness to help.
Since I'm not in coding in any way at all, rather consider myself as a power user, I can't stress enogh how much this community owns to him, and of course to other devs, since there are luckily many others with same knowledge and attitude here at Kodi team.
From your post DaveBlake, I assume you are also quite familiar with coding, and your work and contribution would highly benefit the community to make Kodi even better for plain users, like I am.
Now I started to believe again that with DaveBlake's commitment and FernetMenta's support this feature might get into Kodi some day!
Thanks guys!

[DaveBlake]

Perhaps best start from the beginning.
Can we agree that there is a user requirement to be able to send audio to both a TV (audio to the video device) and to another audio device, in such a way that you can switch easily (e.g. single button press) and instantaneously between them, but not necessarily listen to both at the same time. Switching audio output device needs to be controlable without having to turn on the TV (video device), so that if listening to the TV sound was the last use you don't need to turn on the TV to switch audio output to the other audio device.

ok

Good that is a start.

but not necessarily listen to both at the same time

Requirements need to be unambiguously.

Fair enough. A solution that does allow you to listen to both at the same time would be acceptable, but is not necessary, so I would simply delete those words.

A architectural requirement is: no duplication of audio engine

If we are being picky then that is not a requirement at all but an implementation limitation.

But when it comes to implementation it would be really helpful if you could explain why, from your in depth knowledge of the Kodi architecture, duplication of the current audio engine is such a disaster. Some insights into that aspect of the current audio handling would be useful.

[FernetMenta]

If we are being picky then that is not a requirement at all but an implementation limitation.

I disagree. Meanwhile we have Audio DSP which hooks into the audio engine and it certainly does not for 2 engines. We are talking architecture of the application, not some minor implementations of some features.

I designed ActiveAE not for being duplicated. You can take this as a given or challenge my design in a separate thread. Either way is ok with me.

[AchimTuran]

I disagree. Meanwhile we have Audio DSP which hooks into the audio engine and it certainly does not for 2 engines. We are talking architecture of the application, not some minor implementations of some features.

...

I totaly agree with FernetMenta. Duplicating of that powerful engine (wiki says 22,000 lines of code, I think today there are more )
Using multiple audio devices would be really cool. I also searched for a solution and alot of people say it is not possible to sync them via software. If you search in the internet there are some hardware modders, which synced two audio cards with one crystal.

For example I would use two audio devices to get more channels for playback. A other feature would be multi zone support. One audio device for watching a movie. The other for listening to music in a different room.

But I think its alot of work. You must adapt the source code from the audio engine to support multiple devices. Furthermore the UI needs a huge update to easily support multiple zones.

I can say if you wanna see new features in Kodi, you should start working on it. I think most features where added to Kodi, because some devs want ed to use them.

Here is a good example, which failed in adding AudioDSP add-ons to Kodi: http://forum.kodi.tv/showthread.php?tid=178611
The guy wanted to see this feature, but didn't spend any time to add this feature. Thats not the way Open Source software works.

[Chessie]

In my case, and I'd be curious as to how many other people who use the DA code for the same reason, it's to send audio (music) through out the house and outdoors. I have one amp for my main TV viewing area and a second amp that connects to in-ceiling speakers in every room and outside around the pool. In most cases, modern amps that support zone 2 speakers will not allow the same digital audio stream to both zones at the same time. (Unless they do some tricks like Yamaha's Party Mode amps.) So the DA code allows me to send my play list music to both amps and I then have music though out the house. Works perfectly in my case. Without the DA code I'd probably have to get rid of my fairly new Pioneer Elite and buy a new Yamaha with Party Mode.

[DaveBlake]

I designed ActiveAE not for being duplicated.

I am hoping you mean that you did not consider multiple audio output, which is a shame, rather than you deliberately designed it to prevent multiple output!

You can take this as a given or challenge my design in a separate thread. Either way is ok with me.

I have no interest in challenging you FernetMenta. I have repeatedly, and I indended politely, asked you for a little more information about the audio engine architecture, but clearly you are not going to share that knowledge. That is also a shame.

[FernetMenta]

I am hoping you mean that you did not consider multiple audio output, which is a shame, rather than you deliberately designed it to prevent multiple output!

I think you get something wrong here. Duplicating AE is the worst thing you can do in order to achieve multiple output. That does NOT mean that there are no better ways to do this.

I have no interest in challenging you FernetMenta. I have repeatedly, and I indended politely, asked you for a little more information about the audio engine architecture, but clearly you are not going to share that knowledge. That is also a shame.

Maybe we have a language issue here. I offered my support which is answering questions and assisting evaluating ideas. This is the development section of the forum and I would expect you to look into the code. I am happy to help but I am not going to teach you AE from scratch.

[DaveBlake]

I totaly agree with FernetMenta. Duplicating of that powerful engine (wiki says 22,000 lines of code, I think today there are more)

I' can get that there are flaws in the way DA has been approached in this project, I would just like to know more about what they are. I don't intend to upset anyone, or challenge anyone, I would just like some more information. Lots of code may mean that a lot of work has gone in to create the audio engine (well done everyone), but the strength of object orientation is that masses of well written code can be in a sense duplicated just by instantiating another object of that class. The audio engine may or may not be such an object, I don't know. However this project seems to have got something like that to work, no matter how precariously or with limits, and therefore the idea provokes interest.

Using multiple audio devices would be really cool...

There is a lot more you could do with multiple audio than I have a need for personally. It would be really useful to be able to guage what the interest is in various configurations.

I can say if you wanna see new features in Kodi, you should start working on it. I think most features where added to Kodi, because some devs want ed to use them.

Here is a good example, which failed in adding AudioDSP add-ons to Kodi: http://forum.kodi.tv/showthread.php?tid=178611
The guy wanted to see this feature, but didn't spend any time to add this feature. Thats not the way Open Source software works.

I get that if you want it you have to do it yourself (if you can), I also know that software takes time and effort, got the grey hair to show for it!

But it would be nice to have a little more feedback that "no, no, no it can't be done this way". Right now I am regretting even asking, it seems that people were upset before I started. From working as a senior member of large teams, I am used to having to explain my designs to others, share my knowledge of a project so that they can contribute. I can never just say "no, no, no" no matter how silly the suggestion, but in Opensource I guess it is different, there you just get a mountain of code to read (if you have the time).