From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from firefly.pyther.net ([50.116.37.168]:58172 "EHLO firefly.pyther.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932675Ab2LGLtT (ORCPT ); Fri, 7 Dec 2012 06:49:19 -0500 Message-ID: <50C1D7BD.90609@pyther.net> Date: Fri, 07 Dec 2012 06:49:17 -0500 From: Matthew Gyurgyik MIME-Version: 1.0 To: Devin Heitmueller CC: =?ISO-8859-1?Q?Frank_Sch=E4fer?= , Antti Palosaari , Linux Media Mailing List Subject: Re: em28xx: msi Digivox ATSC board id [0db0:8810] References: <50B5779A.9090807@pyther.net> <50B67851.2010808@googlemail.com> <50B69037.3080205@pyther.net> <50B6967C.9070801@iki.fi> <50B6C2DF.4020509@pyther.net> <50B6C530.4010701@iki.fi> <50B7B768.5070008@googlemail.com> <50B80FBB.5030208@pyther.net> <50BB3F2C.5080107@googlemail.com> <50BB6451.7080601@iki.fi> <50BB8D72.8050803@googlemail.com> <50BCEC60.4040206@googlemail.com> <50BD5CC3.1030100@pyther.net> <50BD6310.8000808@pyther.net> <50BE65F0.8020303@googlemail.com> <50BEC253.4080006@pyther.net> <50BF3F9A.3020803@iki.fi> <50BFBE39.90901@pyther.net> <50BFC445.6020305@iki.fi> <50BFCBBB.5090407@pyther.net> <50BFECEA.9060808@iki.fi> <50BFFFF6.1000204@pyther.net> <50C11301.10205@googlemail.com> <50C12302.80603@pyther.net> <50C1490E.8040203@pyther.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-media-owner@vger.kernel.org List-ID: On 12/06/2012 10:21 PM, Devin Heitmueller wrote: > On Thu, Dec 6, 2012 at 8:40 PM, Matthew Gyurgyik wrote: >> I was able to do a bit of testing tonight and this is what I found. >> >> A channel scan was unsuccessful: >> http://pyther.net/a/digivox_atsc/dec06/scan.txt (no errors in dmesg) >> >> Changing channels by pressing "h" in "mplayer dvb://" caused mplayer to >> crash and this messages to be logged in dmesg >> http://pyther.net/a/digivox_atsc/dec06/dmesg_mplayer_switch_channels.txt > This looks like a combination of a misconfiguration of GPIOs and > mplayer not properly handling an exception condition. You should > definitely bring this up with the mplayer developers since their app > shouldn't crash under this circumstance. Sorry I misspoke. mplayer isn't crashing, however it can't read data from the tuner and thus closes. for completeness, mplayer output: http://pyther.net/a/digivox_atsc/dec06/mplayer_channel_switch.txt > >> Audio is out-of-sync in mplayer. Using cache helps, but over time the audio >> still goes out of sync. >> http://pyther.net/a/digivox_atsc/dec06/mplayer_audio_out_of_sync.txt > This has nothing to do with the tuner. The tuner delivers the MPEG2 > stream already compressed and synchronized. If you're playback is > out-of-sync, it's probably your ALSA drivers, PulseAudio, or mplayer > that is the culprit. Ok that make sense, I'd bank it being on mplayer and how it reads the stream. > >> Using azap to tune and using cat /dev/dvb/adapter0/dvr0 > test.mpg to >> generate a test.mpg >> >> mplayer plays the file fine without audio-sync issues, but VLC and Xine >> refuse to play it. (is this normal?) > What errors are VLC or Xine showing? Unless the stream is really > corrupt VLC and Xine should play it fine. And if the stream were > corrupt it wouldn't play with mplayer either? This sounds like bugs > in VLC and Xine. I would agree with. I got the chance to test another mpeg from my other tuner (that I know works well) and had the same issue. The vlc errors consist of similar messages such as those below: > [0x7f0200c015a8] ts demux warning: lost synchro > [0x7f0200c015a8] ts demux debug: skipping 187 bytes of garbage I had thought I was able to play previous captures in VLC. I was unable to test my other card (that I know works well) last night. Now I see this is not the case, and it separate issue. > There's definitely something going on in the tuner which is causing > the channel scan to fail (and probably the tuning failure in mplayer). > But all the stuff with actual playback causing segfaults, A/V sync > issues, and failures to play back in certain applications are all > userland problems that you would need to raise with the developers for > those respective projects. > > Cheers, > > Devin > > -- > Devin J. Heitmueller - Kernel Labs > http://www.kernellabs.com