[Martijn]

Problem: slow gui and no sound after initial installation (as read through out the forum). AE is setting HD audio by default if this is detected that it could be used however for a lot of people the other end doesn't support this which causes problems.

Solution: disable HD audio by default so it works for the majority of noob users. Audiophiles will find it anyway so no need to bog down the default users who don't understand what is going on.

-----------

Problem: when doing a single single file library import GUI basically locks up for quite some time (~5 minutes), suddenly starts to somewhat respond again showing progress bar. Then locks up again for long time and occasionally updates the progress bar a bit. But during this time you will get an "XBMC not responding" feeling on windows. This is also reported on the forum and imo something that needs to be looked at what is happening.

Solution: get some one well known to this area to look at it. Take it off the GUI thread so GUI at least stays responsive.

[jjd-uk]

Problem: slow gui and no sound after initial installation (as read through out the forum). AE is setting HD audio by default if this is detected that it could be used however for a lot of people the other end doesn't support this which causes problems.

Solution: disable HD audio by default so it works for the majority of noob users. Audiophiles will find it anyway so no need to bog down the default users who don't understand what is going on.

Following on from this I'd go further


Problem: Choppy video and no audio.

When setting Audio Output to the Optical/coax or HDMI options all the capable receiver passthrough items are enabled (apart from AAC capable receiver it seems), however not all systems will support the passthrough of some of the encoded formats such as DTS. This mismatch between what is supported at the OS/driver level and what is enabled in XBMC causes video & audio playback problems that causes much confusion for new or inexperienced users. There has been many occassions where I've had to talk users through finding out what their system supports and then disabling the "capable receiver" items that their av setup does not support.

Solution: In nearly all the cases where choppy video and no audio is experienced, this can be solved by setting Audio Output to Analog so that XBMC sends all audio as PCM with encoded formats such as DTS being decoded by XBMC where necessary. Since XBMC doing the decoding for encoded formats like DTS offers the greatest & simplest compatibility for users then I would suggest that the quick win is that XBMC by default for both the Optical/coax and HDMI options for Audio Output should have all the capable receiver passthrough items disabled. Forcing user to enable the capable receiver items for passthrough if they want to bitstream means they are more likely to investigtate what their system supports or only be touched by experience users, it also has the benefit of the users more likely having an initially working setup thus if they enable any of those items then experience problems then it should hopefully be obvious to them they need to be disabled again.

Perhaps in the long term the enumeration of the audio devices by XBMC can be used to set the defaults for the capable receiver passthrough items.

Hope that all makes sense.

[DDDamian]

Problem: slow gui and no sound after initial installation (as read through out the forum). AE is setting HD audio by default if this is detected that it could be used however for a lot of people the other end doesn't support this which causes problems.

Solution: disable HD audio by default so it works for the majority of noob users. Audiophiles will find it anyway so no need to bog down the default users who don't understand what is going on.

Following on from this I'd go further


Problem: Choppy video and no audio.

When setting Audio Output to the Optical/coax or HDMI options all the capable receiver passthrough items are enabled (apart from AAC capable receiver it seems), however not all systems will support the passthrough of some of the encoded formats such as DTS. This mismatch between what is supported at the OS/driver level and what is enabled in XBMC causes video & audio playback problems that causes much confusion for new or inexperienced users. There has been many occassions where I've had to talk users through finding out what their system supports and then disabling the "capable receiver" items that their av setup does not support.

Solution: In nearly all the cases where choppy video and no audio is experienced, this can be solved by setting Audio Output to Analog so that XBMC sends all audio as PCM with encoded formats such as DTS being decoded by XBMC where necessary. Since XBMC doing the decoding for encoded formats like DTS offers the greatest & simplest compatibility for users then I would suggest that the quick win is that XBMC by default for both the Optical/coax and HDMI options for Audio Output should have all the capable receiver passthrough items disabled. Forcing user to enable the capable receiver items for passthrough if they want to bitstream means they are more likely to investigtate what their system supports or only be touched by experience users, it also has the benefit of the users more likely having an initially working setup thus if they enable any of those items then experience problems then it should hopefully be obvious to them they need to be disabled again.

Perhaps in the long term the enumeration of the audio devices by XBMC can be used to set the defaults for the capable receiver passthrough items.

Hope that all makes sense.

Quite agree! The enumerations will be used for enabling/disabling default "receiver-capable" settings - that's coming. They can still be overridden by the user.

I'd made the argument some time ago that the whole "analog/optical/HDMI" setting is redundant now - it just confuses users as it has nothing to do with where the audio is sent. It provides general guidelines only e.g. no DTS-HD over optical etc.

It would be just as easy to remove that setting, default on install to basic 2.0, no passthrough (decode all) and have a radio button for "Enable reported formats" to go with the enumeration settings, or if not checked allow users to manually select the "receiver-capable" buttons.

That *should* be an out-of-the-box sound works scenario, with one button to enable all the reported formats, and a manual override in case they're wrong or if a user wants to force decoding of a specific format.

[jjd-uk]

It would be just as easy to remove that setting, default on install to basic 2.0, no passthrough (decode all) and have a radio button for "Enable reported formats" to go with the enumeration settings, or if not checked allow users to manually select the "receiver-capable" buttons.

That *should* be an out-of-the-box sound works scenario, with one button to enable all the reported formats, and a manual override in case they're wrong or if a user wants to force decoding of a specific format.

That sounds good to me.

Personally I'd also like to see a new Audio section in System Info which displays all the enumerated info, I think this is something you started work on if I rightly remember.

[jmarshall]

Problem: when doing a single single file library import GUI basically locks up for quite some time (~5 minutes), suddenly starts to somewhat respond again showing progress bar. Then locks up again for long time and occasionally updates the progress bar a bit. But during this time you will get an "XBMC not responding" feeling on windows. This is also reported on the forum and imo something that needs to be looked at what is happening.

Solution: get some one well known to this area to look at it. Take it off the GUI thread so GUI at least stays responsive.

This is actually due to the time to read/parse the XML. i.e. the first thing that happens is we load the XML, log, throw up dialog. The log will be after that 5 minutes. I'm not sure yet where the XML reading is slow (reading, parsing, some of the remapping we do for system tiny?) but I suspect the latter. Yes, it could be done off-thread, but fixing the slow XML reading should take priority as that will basically take care of the problem here and elsewhere.

Cheers,
Jonathan