[mythtv] [mythtv-commits] Ticket #6569: ac3 level is low for 5.1 source

[Mark Spieth]

On 6/05/2010 12:57 PM, Jean-Yves Avenard wrote:
> Hi
>
> On 6 May 2010 09:54, Mark Spieth<mark at digivation.com.au>  wrote:
>    
>> however auto switching between 2 and 6 ch mode in ac3 is currently broken.
>> It currently only goes from 6 to 2 ch mode and never goes back to 6 ch mode.
>>      
> The only time I can think 2 channels won't go back to 6, if when you
> have weird stream that does 6 ->  2 ->  6 ->2 ->  6
>
>    
OneHD does this all the time. motogp/f1 is in ac3 5.1 ads are in ac3 2.0
> I added a special case where if too many changes occurred too quickly,
> it would stop the change any further.
> This was to fix a few tickets
>
>    
ok. may need a flag to enable/disable functionality but auto is better.
>> jya, we need a reconfigure mode that allows seemless upmix/source channel
>> changes without killing audio to swap between 2-6ch upmix and native 6ch
>> mode. should be easy.
>>      
> I'm a bit scared with your definition of "easy" :)
>
>    
upmixer has 2 and 6 ch mode. of source material is 6 ch it just copies 
with the same audio latency (I think) so it can handle it seemlessly. 
just need to tell it the #source channels and it should do the correct 
thing to get the resultant 6 channels out. shoudl work for mono too. the 
other separate mono upmix should have been done there too.

we could add a further mode where we tell upmixer whether its in int16 
or float source format too so it will use whatever is fed to it.

> I can't think of an easy way to perform a seemless upmix and native 6 channels.
> You will have to reset the audio buffer. We do not support a change of
> format in the middle of the audio support (don't see how the excessive
> extra work would be worth it too).
> If you have timestretch on, this would be even more difficult
>
>    
timestretch is after upmix in the dataflow and is thus independent. 
always in output channel size mode.
> In the new hdaudio too, this is even more complicated by the fact the
> format in the audio buffer would usually change between FMT_S16 and
> FMT_FLOAT when upmix is activated
>
> If we were to only deal with floats all the time, it would ease things
> but it is still a rather significant job.
>
> Currently, we recalculate all actions to be performed in one go in the
> Reconfigure function...
> Splitting that one up, to only redo partial calculations is a bit of a
> head-aches, especially as often it's a combination of criteria that
> trigger a processing.
>
> Also, going from say 2 upmix 6 to native 6 doesn't mean the audio card
> doesn't have to be reset either.
>    
correct which is why I say what I say.
> As we know support various formats, it could be that the native 6 has
> been decoded as FMT_32 or FMT_FLOAT, (depending on what the audio
> cards ask for, jack and coreaudio asks for floats) while upmixed AC3
> would be FMT_S16
>
> resampling may have to be done too etc...
>
> So really... it's no easy job.
> There are big ramifications to consider. And I'm not sure
> recalculating things so you only close/reopen the audio card only when
> necessary is worse the trouble.
>
>    
the audio card should only need to be reopened if the #output channels 
changes, which should be never for a session.
the dataflow of the audio system ensures that.

mark