Sonicview 8000HD Audio Dropouts

[zamar23]

Anyone experiences periodic audio dropouts by Sonicview SV-8000HD each 10-15 sec on many clear audio only (radio) channels of G19? I.e., Test 243 (Country Music) channel drops continuosly for 1-2 sec regardless of AUDIO OUT Port and output signal format used. What causes this, and how to fix? On SV Elite 360 there are no such audio problems with the same channels ever.

 

[AcWxRadar]

Anyone experiences periodic audio dropouts by Sonicview SV-8000HD each 10-15 sec on many clear audio only (radio) channels of G19? I.e., Test 243 (Country Music) channel drops continuosly for 1-2 sec regardless of AUDIO OUT Port and output signal format used. What causes this, and how to fix? On SV Elite 360 there are no such audio problems with the same channels ever.

Zamar,

Odd that you should ask this. I was experiencing just the very same thing - audio (radio) channels only. I first noticed this on the Test 243 channel on IA5 @ 97.0W. I tried several other sats and found the problem on them, too.

Every ten seconds, the audio would just go blank and then come right back on (one second or less dropout).

However, I was using an AZBox Premium. I had my Coolsat 5000 connected to the loop out connection on the AZBox, so it was getting its signal from the same source and the audio was not dropping out on the Coolsat.

This was within the last week or so and now, this weekend, it is just fine - no audio dropouts on any channel on the AZBox.

Are you still detecting it? Does it come and go at random or is it always doing this? Try rebooting the receiver or possibly update or reload the firmware, if that is simple for your SV.

I don't know why the problem corrected for me and my AZBox. I have been doing a lot of stuff with the box and I may have inadvertently fixed it by upgrading the image or else it just self corrected.

I just thought that it was peculiar that you reported this with a totally different receiver than what I am using, but that the symptoms were so identical - you even mentioned the Country Music Channel on 97, which is where I first observed it.

Bizarre!

RADAR

 

[zamar23]

Hi AcWxRadar,

I listen this clear country music channel the most, and it gives me now the biggest headache with SV8000HD respectively. I just checked, and NO - it continues the same odd behavior indefinitely without any respect to your more polite AZBox. I wonder if its a firmware issue - if one assumes that Audio Codecs Set is part of the firmware package, and not hard engraved in its A/V Proc. It plays normally half of the various radio channels on G19, and drops continuously for 1 sec the other half. I just get it from Fleabay, didn't check firmware version yet. But it might be all firmware versions have very same audio codecs set. I also noticed, it takes awhile for any SV model to start playing the Radio channel, it drops audio on. Possibly looking for the right codec, and not finding the optimal one. And then having problem with processing the stream. I guess, with AZBox the issues is more easily curable due to major differences in firmware approach. Anyone found how to fix this in SV8000HD? It doesn't happen on TV channels - at least I didn't observe it yet on any sat with my motorized setup.

 

[madmadworld]

had a SV8000HD over 2 years the radio never has been good. i don't use fta radio much but when i feel like testing it always did poorly compared to my other boxes. but it does everything else very well. will record higher bit rate than my AZbox at this time.
good luck

 

[B.J.]

This probably is unrelated, but there has been something bothering me about listening to audio from DVB muxes, and that is, is a PCR necessary to listen to audio?
If you look up the definition of PCR, it indicates that it is used to sync audio and video, so you would think that to listen to audio only, that you wouldn't need a PCR. However if you try to create an audio only channel in a program like TSREADER, it insists on knowing what the PCR PID is. I asked the question about this over at another forum which has some extremely knowledgeable people, and I was told that the PCR is requirred, even if it's only audio that you're playing. This really confuses me. It doesn't seem like the PCR should be necessary for just audio, and I have seen the TSREADER display for some audio only channels that don't mention any PCR, so it seems like it IS possible to play audio without the receiver knowing about the PCR.
Only thing I can think of is that some audio, particularly audio channels on muxes with a lot of audio channels or on muxes with video as well, that the audio is sent in little packets that are separated by packets of other audio and video, and the receiver needs to somehow determine the bitrate of the audio to know how fast to play it. Seems like without using a PCR, that the receiver might play the audio too fast, and it will finish one packet's worth of audio before the next packet comes in, leaving a gap of no sound for a while.

Anyway, the reason I thought that this might be related to this topic is that perhaps different receivers have different ways of playing audio that might not be delivered in a mux that has a PCR associated with the audio. Ie some receivers might try to calculate bitrates to decide how fast to play the audio, other receivers might just play it as fast as it can or guess at how fast to play it, leaving audio gaps if it guessed wrong and played it too fast. So I guess the question is, does the channel data for these channels that give poor audio list a PCR PID, or just the audio PID??
Just curious, and also just hoping that someone knowledgeable in satellite audio might comment on the need for a PCR when playing audio only, both for real audio only channels, but also for playing only the audio from an audio/video channel. Ie I used to like to stream the audio only from some video channels, but was forced to also stream the video channel even though I wasn't using that, since it had the PCR data, and this was a waste of bandwidth.

 

[AcWxRadar]

This probably is unrelated, but there has been something bothering me about listening to audio from DVB muxes, and that is, is a PCR necessary to listen to audio?
If you look up the definition of PCR, it indicates that it is used to sync audio and video, so you would think that to listen to audio only, that you wouldn't need a PCR. However if you try to create an audio only channel in a program like TSREADER, it insists on knowing what the PCR PID is. I asked the question about this over at another forum which has some extremely knowledgeable people, and I was told that the PCR is requirred, even if it's only audio that you're playing. This really confuses me. It doesn't seem like the PCR should be necessary for just audio, and I have seen the TSREADER display for some audio only channels that don't mention any PCR, so it seems like it IS possible to play audio without the receiver knowing about the PCR.
Only thing I can think of is that some audio, particularly audio channels on muxes with a lot of audio channels or on muxes with video as well, that the audio is sent in little packets that are separated by packets of other audio and video, and the receiver needs to somehow determine the bitrate of the audio to know how fast to play it. Seems like without using a PCR, that the receiver might play the audio too fast, and it will finish one packet's worth of audio before the next packet comes in, leaving a gap of no sound for a while.

Anyway, the reason I thought that this might be related to this topic is that perhaps different receivers have different ways of playing audio that might not be delivered in a mux that has a PCR associated with the audio. Ie some receivers might try to calculate bitrates to decide how fast to play the audio, other receivers might just play it as fast as it can or guess at how fast to play it, leaving audio gaps if it guessed wrong and played it too fast. So I guess the question is, does the channel data for these channels that give poor audio list a PCR PID, or just the audio PID??
Just curious, and also just hoping that someone knowledgeable in satellite audio might comment on the need for a PCR when playing audio only, both for real audio only channels, but also for playing only the audio from an audio/video channel. Ie I used to like to stream the audio only from some video channels, but was forced to also stream the video channel even though I wasn't using that, since it had the PCR data, and this was a waste of bandwidth.

B.J.

This may very well have something to do with the audio dropouts that both Zamar and I were detecting. Recall that I mentioned that it was only a problem with my AZBox and the Coolsat, running off the loop out port of the AZBox, did not present this problem.

Why it corrected itself for me, I cannot say, but your theory seems logical, or at least a good place to begin investigating.

RADAR

 

[AcWxRadar]

Through some experimentation with the AXBox Premium, I found that this audio drop-out is present with image file (firmware) 2880 but is corrected with image file 3281.

Zamar, you might try a different firmware file for your SV8000HD and see if you can correct it that way.

RADAR

 

[zamar23]

Thanks AcWxRadar. I'll see if its possible without other trade-offs. It might be that new SV firmware updates target different goals than AZBox updates, and less devoted to sideway bug fixing or new features.

B.J.

Answers.com gives the following definition (which eludes practical application details):
"PCR stands for Program Clock Reference. It is used to sync the audio and video. PCR keeps the system clock synced. If the system clock starts to rift, it is rectified using the PCR value."

It looks like you may have pinpointed the right direction to look at, but possibly not exactly. The STB shows for G19 Test 243 clear radio channel: VID-8192, AUD-1424, PID-1424. I.e., PID value is present, though it might be derived from another value like AUD, and be inaccurate, but remains the same for SV8000 and SV360, while 360 plays the audio channels flawlessly, and 8000 with constant interruptions. Some sources suggest to set PID to 8190 or 8191, but not sure how it's relevant to Audio only channels. Will try some play, and see what happen. Can you check with TSReader, what the actual values are for this particular Test 243 channel? Satcodx gives the same data. It looks more and more like a never fixed old firmware issue, most SV users never payed attention to.

 

[madmadworld]

what tp is it ?
i have only 8 stations saved. and have only 30 radio and no pids you speak of.
will test my frimware.

edit. just checked them only 7 worked.
this box does not like audio. did the shim shake.

Thanks AcWxRadar. I'll see if its possible without other trade-offs. It might be that new SV firmware updates target different goals than AZBox updates, and less devoted to sideway bug fixing or new features.

B.J.

Answers.com gives the following definition (which eludes practical application details):
"PCR stands for Program Clock Reference. It is used to sync the audio and video. PCR keeps the system clock synced. If the system clock starts to rift, it is rectified using the PCR value."

It looks like you may have pinpointed the right direction to look at, but possibly not exactly. The STB shows for G19 Test 243 clear radio channel: VID-8192, AUD-1424, PID-1424. I.e., PID value is present, though it might be derived from another value like AUD, and be inaccurate, but remains the same for SV8000 and SV360, while 360 plays the audio channels flawlessly, and 8000 with constant interruptions. Some sources suggest to set PID to 8190 or 8191, but not sure how it's relevant to Audio only channels. Will try some play, and see what happen. Can you check with TSReader, what the actual values are for this particular Test 243 channel? Satcodx gives the same data. It looks more and more like a never fixed old firmware issue, most SV users never payed attention to.

 

[zamar23]

madmadworld

Test 243 is about the only pleasant to listen Radio Channel on G19 for many FTA fans, and its on: 11991 22000 V 3/4 . Its Country Music at its best. SV8000 can blind scan it, but not every time: try blind scan second and third time, erasing the sat each time to avoid duplicate channels.

 

[madmadworld]

scaned in first time.
but will not play a lick with my factory firmware.
not surpised.
it was on my pan 9000 plays fine.
good luck
sorry could not fix this.

madmadworld

Test 243 is about the only pleasant to listen Radio Channel on G19 for many FTA fans, and its on: 11991 22000 V 3/4 . Its Country Music at its best. SV8000 can blind scan it, but not every time: try blind scan second and third time, erasing the sat each time to avoid duplicate channels.

 

[B.J.]

I just scanned in this 11991 transponder into my Diamond 9000, and it scanned in fine, and that test channel plays fine without any outages.

I have the passthru of the 9000 going to my Twinhan with TSREADER, and it shows this TEST 243 as a separate channel which only lists the Audio PID, no PCR PID. TSREADER shows Audio: Bitrate 64 Kbps Sample Rate 44.1 KHz.

So, it doesn't seem like a PCR is involved here, unless perhaps the receiver in question doesn't have a good clock. Ie, I'm wondering if the receivers are deciding how fast to play the audio from the above bitrate/sample rate data, but if the clocks are off in the receiver, perhaps it plays it too fast, resulting in occasional outages??? Perhaps on audio channels with associated PCR PIDs have the rate constantly adjusted so that the outages don't occur??? I'm just guessing here.
So maybe my Diamond has a better clock oscillator than the receivers that are having problems???

 

[madmadworld]

this was one of the first HD FTA boxes at least over here, i figure the guy was working so hard on the picture and getting the pvr right.
and forgot about the radio. thought he had it. got rushed.

 

[zamar23]

B.J.

It looks like when PCR value is missing, SV assigns it equal to VID value (for video channels) or AUD (for audio only channels with VID=8192), since its firmware seems to expect some PCR value for every channel. It's probably not used after that, as I created a channel without it, and it works (also with dropouts). As to SV having inaccurate clock - I doubt it. The receivers are some of the best of that generation, made by a South Korean division of a known telco company Eycos (former Satforce), Austria, who does the design in both places - its a 4-th gen. refined product. But its customized firmware sucks big time when it comes to FTA related functions and features. The case with FTA Audio channels confirms that: this known issue wasn't addressed by "Team SV" since SV brough the receiver to market.

On a side note, ChannelMaster Channel Editor has being updated to V1.20.03 some time ago, and now supports Channel List files of most current receivers on the market, including all SV models.

 

[B.J.]

B.J.

It looks like when PCR value is missing, SV assigns it equal to VID value (for video channels) or AUD (for audio only channels with VID=8192), since its firmware seems to expect some PCR value for every channel.
It's probably not used after that, as I created a channel without it, and it works (also with dropouts).

The way I understand it, 8192 is not a legal number for a PID. I think 8191 (the NULL PID) is the highest legal number. Using 8192 is essentially not giving it a PID#, but I think different receivers do different things when they see an 8192.
I know that I used to use a program called DVBAPPS quite often with my Twinhan, before I learned to use VLC, and very often DVBAPPS wouldn't work if you gave it the proper PCR PID, so the trick was to enter 8192, and then for some reason it would work. I was told that in this situation the program was proabably automatically using the video PID, but since the video PID was what I HAD been entering unsucessfully, I'm thinking that using 8192 made it just ignore the PCR, which I think is what you were suggesting above.

 

[AcWxRadar]

The way I understand it, 8192 is not a legal number for a PID. I think 8191 (the NULL PID) is the highest legal number. Using 8192 is essentially not giving it a PID#, but I think different receivers do different things when they see an 8192.
I know that I used to use a program called DVBAPPS quite often with my Twinhan, before I learned to use VLC, and very often DVBAPPS wouldn't work if you gave it the proper PCR PID, so the trick was to enter 8192, and then for some reason it would work. I was told that in this situation the program was proabably automatically using the video PID, but since the video PID was what I HAD been entering unsucessfully, I'm thinking that using 8192 made it just ignore the PCR, which I think is what you were suggesting above.

I was just looking at a RADIO channel on 30.0W (Hispasat) and it shows a PPID of 8191 and also a VPID of 65535. These were assigned to the radio channel by the receiver itself.

If I remember correctly, I once tried to alter these (just experimenting) and the receiver would not allow me to do so. I am surmising that if the receiver knows it is a radio channel, it automatically assigns its own default (null) specifications.

Just thinking out loud here.

RADAR

 

[B.J.]

I was just looking at a RADIO channel on 30.0W (Hispasat) and it shows a PPID of 8191 and also a VPID of 65535. These were assigned to the radio channel by the receiver itself.

If I remember correctly, I once tried to alter these (just experimenting) and the receiver would not allow me to do so. I am surmising that if the receiver knows it is a radio channel, it automatically assigns its own default (null) specifications.

Just thinking out loud here.

RADAR

Yeah, the actual value found in the satellite stream is just a 12 bit number, so both 8191 and 65535 are the same value if you look at the last 12 bits, ie the null stream.
I seem to remember a discussion a while back about some receiver that was using A/V PID numbers that were higher than 8191, and I used those numbers to generate numbers from the last 12 bits, and it turned out to be the published A/V PIDs. I forget what receiver that was.
I also remember trying to figure out how to get the Diamond 9000 to use MPEG4 for a manually channel created by entering PIDs, since the channel editor didn't have an option for MPEG4. Well it turned out that if you add &H4000 to the video PID, that the receiver would assume that channel was mpeg4 video. So the receiver was using part of the number for the PID and part of the number for the video type. Same thing was true for audio channels, ie to indicate mpeg or AC3, etc. Anyway, only the rightmost 12 bits are used for the PID, and the receiver might be doing other things with the bits to the left.
But in these cases, it's just ignoring the PIDs since it's using the null stream.

 

[zamar23]

For those experiencing continuous split-second Audio drop outs on radio channels, I found a temporary fix till firmware fix is available:

- Select a TP transmitting your favorite dropping Radio Channel
- Look through Video Channels on that TP to remember their VID
- Add a new fake Video Channel with VID=value not used (less than 8192), AUD=value of your Audio Channel, PCR=VID
- Add Channel Name and Save
- Add this channel to Video Favorites
- Switch to it and enjoy clear uninterrupted Radio

It works for Test 243 on G19 beautifully, added to TP11991 with PID=7390, AUD=1424, PCR=7390. And it will work for your favorite Radio Channel too. :up