[mythtv-commits] Ticket #12827: Raspberry Pi: Digital Audio does not work

[MythTV]

#12827: Raspberry Pi: Digital Audio does not work
----------------------------------+-----------------------------
 Reporter:  pbennett              |          Owner:  pbennett
     Type:  Bug Report - General  |         Status:  accepted
 Priority:  minor                 |      Milestone:  unknown
Component:  Ports - rPi           |        Version:  Master Head
 Severity:  medium                |     Resolution:
 Keywords:                        |  Ticket locked:  0
----------------------------------+-----------------------------

Comment (by pbennett):

 Thank you for the detailed review. I appreciate your comments. Many of
 these are issues I have been struggling with over the last few weeks. Here
 are my thoughts and responses.

 The reason I deleted omx decoder is that it was in the same source file as
 the omx renderer code. Some code was similar between the two classes and
 it was confusing to me. I was fixing errors in the decoder and wondering
 why nothing was changed. The decoder was running and putting out error
 messages, although it was never actually being passed any data. The source
 is still in github if you look back to the correct version. How would you
 propose disabling it? I could put it in a separate file that is never
 compiled. Is that better? I think that could also be confusing for people.
 Having dead code around also adds work for those who do not know it is
 dead code and are doing some sort of maintenance, for example updating
 logging throughout the system if there is a new logging method. Also
 people looking to fix a problem could waste time looking through the dead
 code, like I did.

 The constraint on diverge (DIVERGELIMIT 30) may have been intended as a
 sort of governor, but the way it was implemented had no effect other than
 making logging messages incorrect. If the divergence is more than
 MAXDIVERGE (3), the action is the same, drop a frame or double the rate,
 depending on the sign of the divergence. It makes no difference to the
 logic how much it diverges. The expectation is next time you come into the
 routine the divergence will be less due to the previous action, until
 eventually it is less than MAXDIVERGE.

 I have been pondering the reasons for the audio rate issue. At one point I
 thought it was calculating based on frame sizes and should have been using
 compressed audio rate, since the audio being passed through is compressed.
 However when I changed to use a calculation based on bitrate, audio sync
 was way off, and still jumping around from too slow to too fast and back
 again. We are not using a re-encoder, and pulseaudio is turned off.
 OpenMAX audio bypasses both ALSA and pulseaudio and seems to talk directly
 to the hardware. Using the average calculation seems to give a good
 result, but adjustments to the sync will be more gradual so anything which
 needs frequent adjustments will not work well.

 Pulling the avsynv averaging number from the device class - I thought
 about this and it seemed it is probably not something many classes would
 use. If you think that is better I will do it. I have to make sure of the
 timing of creating of the audio output class to make sure it is available
 at the time we need to get the numbers.

 Are you suggesting I should have separate settings for AVSyncAveraging and
 OMXHDMIAVSyncAveraging? The setting I am using for AVSyncAveraging as I
 have created it will override for all audio types. I see it mainly as a
 testing tool. If end users actually make use of it they probably only need
 1 setting. They can set it for their current audio selection, which should
 not change often.

 avsync_interval = avsync_averaging / 3 - 1; The 3 here is to set a
 reasonable rate for divergence checking. It is based on the max_diverge.
 The value of 3 should actually be specified as max_diverge. I will change
 it. When averaging the divergence over 60 frames instead of 4, it takes
 much longer for a change to be reflected in the divergence, so I need to
 space out the frequency of checking for divergence. So I only check
 divergence every 20 frames.

 diverge is 0 when avsync_next is not set. This is to force adjustments to
 occur only every avsync_interval. By having diverge as 0 no adjustment
 (dropping or speeding frame) is done at that frame. In the default case
 where averaging is 4, divergence is calculated every time.

--
Ticket URL: <https://code.mythtv.org/trac/ticket/12827#comment:7>
MythTV <http://www.mythtv.org>
MythTV Media Center