home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
Development
General Development (no feature request here!)
MediaPortal Audio renderer - better video playback quality
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="arion_p" data-source="post: 642175" data-attributes="member: 45945"><p>First of all, currently we are only time-stretching, not resampling the audio. I do not know if we will need to resample, but so far I see no need.</p><p></p><p>Regarding the phase coherency, I am quite aware of the problem and have examined the code of the above solution (in fact at first I was wondering why ReClock did such "weird" tricks with SoundTouch). Adapting SoundTouch for multichannel is pretty much out of the question for two reasons:</p><p></p><ol> <li data-xf-list-type="ol">It would take a lot of time/work to do it right, as it would have to be done using MMX/SSEx/3Now to be usable</li> <li data-xf-list-type="ol">It would be too slow for most systems. The way soundtouch works is by calculating the auto-correlation of the samples. If we increase the number of channels we also increase the time it takes to calculate the auto-correlation and the increase is exponential.</li> </ol><p>The solution I have used is similar to the above proposed, only it is a bit more flexible:</p><p></p><ol> <li data-xf-list-type="ol">the code will try to process related channels in pairs (i.e. a left/right pair for each Front, Side, Rear, Top, Bottom)</li> <li data-xf-list-type="ol">the channels that are not related to each other, will be processed by pairing each of them with a composite channel</li> <li data-xf-list-type="ol">the composite channel will be calculated based on the average of the dominant channel pair (in order of priority: Front left/right or Side left/right or Rear left/right etc). I have not yet decided what are the correct priorities for selecting dominant channel pair, but these will be easy to change within the code</li> </ol><p>This solution will ensure that each left/right channel pair retains phase coherency, single channels will be coherent to the dominant channel pair (where most of the audio comes from), BUT channel pairs may be incoherent to each other. Fortunately our architecture allows us to switch to a different scheme, that processes each channel paired to the composite channel, so that each channel is coherent to the dominant channel pair or to the average of all channels and in essence coherent to each other. Unfortunately this will also increase CPU usage (by how much it remains to be seen).</p></blockquote><p></p>
[QUOTE="arion_p, post: 642175, member: 45945"] First of all, currently we are only time-stretching, not resampling the audio. I do not know if we will need to resample, but so far I see no need. Regarding the phase coherency, I am quite aware of the problem and have examined the code of the above solution (in fact at first I was wondering why ReClock did such "weird" tricks with SoundTouch). Adapting SoundTouch for multichannel is pretty much out of the question for two reasons: [LIST=1] [*]It would take a lot of time/work to do it right, as it would have to be done using MMX/SSEx/3Now to be usable [*]It would be too slow for most systems. The way soundtouch works is by calculating the auto-correlation of the samples. If we increase the number of channels we also increase the time it takes to calculate the auto-correlation and the increase is exponential. [/LIST] The solution I have used is similar to the above proposed, only it is a bit more flexible: [LIST=1] [*]the code will try to process related channels in pairs (i.e. a left/right pair for each Front, Side, Rear, Top, Bottom) [*]the channels that are not related to each other, will be processed by pairing each of them with a composite channel [*]the composite channel will be calculated based on the average of the dominant channel pair (in order of priority: Front left/right or Side left/right or Rear left/right etc). I have not yet decided what are the correct priorities for selecting dominant channel pair, but these will be easy to change within the code [/LIST] This solution will ensure that each left/right channel pair retains phase coherency, single channels will be coherent to the dominant channel pair (where most of the audio comes from), BUT channel pairs may be incoherent to each other. Fortunately our architecture allows us to switch to a different scheme, that processes each channel paired to the composite channel, so that each channel is coherent to the dominant channel pair or to the average of all channels and in essence coherent to each other. Unfortunately this will also increase CPU usage (by how much it remains to be seen). [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Development
General Development (no feature request here!)
MediaPortal Audio renderer - better video playback quality
Contact us
RSS
Top
Bottom
