Hello.
It is a known fact that to get the video working in
Russia (secam-d/k) with some saa7134-based cards (mine
is AverTV 307), the one have to add the magic string
options tda9887 secam=d
to their modprobe.conf. (since 2.6.18-rc1 it is an option
of "tuner", not "tda9887", so the magic string is now
different and people will be confused again)
However, the magic string to get the sound working, seem
to be non-existant. I.e. the above option only gets you
the picture but not the sound.
I queried this list a year ago and got the reply that this
problem is known, but nothing changed since then, AFAICS.
Attached patch is a quick hack to get the sound working.
For Russia you'll need to add the following magic string to
the modprobe.conf to get that working:
options saa7134 secam=d
With that patch I've finally got sound from my AverTV card.
I realize that such a solution is not clean, but it works
(for me) and it should not be much worse than the one of
the tuner-core.c, as I simply copy/pasted the related code.
Would it be possible to get that patch applied?

Hi,

Stas Sergeev wrote:
Hello.

It is a known fact that to get the video working in
Russia (secam-d/k) with some saa7134-based cards (mine
is AverTV 307), the one have to add the magic string
options tda9887 secam=d
to their modprobe.conf. (since 2.6.18-rc1 it is an option
of "tuner", not "tda9887", so the magic string is now
different and people will be confused again)
However, the magic string to get the sound working, seem
to be non-existant. I.e. the above option only gets you
the picture but not the sound.
I queried this list a year ago and got the reply that this
problem is known, but nothing changed since then, AFAICS.

Attached patch is a quick hack to get the sound working.
For Russia you'll need to add the following magic string to
the modprobe.conf to get that working:
options saa7134 secam=d

With that patch I've finally got sound from my AverTV card.
I realize that such a solution is not clean, but it works
(for me) and it should not be much worse than the one of
the tuner-core.c, as I simply copy/pasted the related code.
Would it be possible to get that patch applied?

Sorry, the patch can not be applied this way.
The standard fixup: secam=d is no magic and its necessary
for multistandard capable tuner components. Such a fixup is
there for the tuner but it is probably not propagated to the
meged tda9886 driver, we have to check.
The saa713x driver has a automatic standard seach for sound
IF but it seems not to be very reliable. If we can't improve this,
it might be a good idea to force it here as well but this is
a different issue and its is not addressed by your patch.

Best regards
Hartmut

Hi.

Hartmut Hackmann wrote:
The standard fixup: secam=d is no magic and its necessary
for multistandard capable tuner components.
Yes, but for the users I think it is just a magic string, that's
the point. As a user, I'd like to just being able to select secam-d/k
right out of tvtime GUI. But instead I have to select PAL in tvtime
(yes PAL, not even SECAM) and write secam=d in modprobe.conf.
Since this is counter-intuitive and confusing and poorly documented,
I call it a magic string.

Such a fixup is
there for the tuner but it is probably not propagated to the
meged tda9886 driver, we have to check.
It is - since 2.6.18-rc1. Before, you had to add that option
for tda9887 explicitly. Unfortunately it doesn't affect sound.
That option works perfectly, but it gives you only the picture,
and I want to have the sound too. :)

The saa713x driver has a automatic standard seach for sound
IF but it seems not to be very reliable. If we can't improve this,
it might be a good idea to force it here as well but this is
a different issue and its is not addressed by your patch.
Could you please elaborate on that? My original idea was exactly
that - to force the standard, because the detection, well, "unreliable"
is not the right word here perhaps.
There is nothing wrong if my patch can't be aplied as-is. I am
willing to improve it per your suggestions because I want my tuner
to finally work out right. Please tell me what exactly is wrong with
my patch and I'll try to fix it.

Hi

Stas Sergeev wrote:
Hi.

Hartmut Hackmann wrote:

>The standard fixup: secam=d is no magic and its necessary
>for multistandard capable tuner components.

Yes, but for the users I think it is just a magic string, that's
the point. As a user, I'd like to just being able to select secam-d/k
right out of tvtime GUI. But instead I have to select PAL in tvtime
(yes PAL, not even SECAM) and write secam=d in modprobe.conf.
Since this is counter-intuitive and confusing and poorly documented,
I call it a magic string.

I basically agree to this. But who knows what the difference between
i.e. system G and system D is? And which of the countless variants is
used in which country? MS derives this from the specified country but
this isn't really good either
Maybe we should allow to set the full standard through the application
but this list is long. I.e. there is not only a SECAM D but also a PAL D.
You might have a look at the ITU BT470.

>Such a fixup is
>there for the tuner but it is probably not propagated to the
>meged tda9886 driver, we have to check.

It is - since 2.6.18-rc1. Before, you had to add that option
for tda9887 explicitly. Unfortunately it doesn't affect sound.
That option works perfectly, but it gives you only the picture,
and I want to have the sound too. :)

>The saa713x driver has a automatic standard seach for sound
>IF but it seems not to be very reliable. If we can't improve this,
>it might be a good idea to force it here as well but this is
>a different issue and its is not addressed by your patch.

Could you please elaborate on that? My original idea was exactly
that - to force the standard, because the detection, well, "unreliable"
is not the right word here perhaps.
There is nothing wrong if my patch can't be aplied as-is. I am
willing to improve it per your suggestions because I want my tuner
to finally work out right. Please tell me what exactly is wrong with
my patch and I'll try to fix it.

these B-G-D-K letters specify 2 things:
- Sound IF frequencies and modulation
- Video IF, modulation and channel width.
So part of the information needs to go to the IF chip, i.e. the TDA9886.
The other part can go to the audio section of the saa713x to reduce the
search range for the sound standard.
The rest could go to the video section but this makes little sense since
the video standard detection is reliable.
I need to investigate whether the standard fixup is complete for the
moved tda9886 code.

Best regards
Hartmut

Hi.

Hartmut Hackmann wrote:
Maybe we should allow to set the full standard through the application
but this list is long. I.e. there is not only a SECAM D but also a PAL D.
Yes, but at the end the user *have* to select the standard,
one way or another. The list may be long, but seeing it entirely
in the tvtime gui, or choosing the wrong one in gui and then using
the "magic strings" to force the right one - what is more confusing?
Btw, I still don't understand why I select PAL in tvtime rather than
SECAM to get secam=d working - is this not a bug?

these B-G-D-K letters specify 2 things:
- Sound IF frequencies and modulation
- Video IF, modulation and channel width.
So part of the information needs to go to the IF chip, i.e. the TDA9886.
Yes, that's what the "tuner" option does. It goes to TDA9887 (not 9886 btw :)
and gives me the right video. So the option apparently works as expected.

The other part can go to the audio section of the saa713x to reduce the
search range for the sound standard.
Which is exactly what my patch implements. So what are the concerns?

I need to investigate whether the standard fixup is complete for the
moved tda9886 code.
I am sure it is. Before the tda9887 code was moved, I used that option
for "tda9887" and it used to give me video and no sound. Now, as it was
moved, I use that option for "tuner" and again it gives me the video and
not the sound. So I am quite sure that option works as expected and goes
to tda9887 very well, otherwise I wouldn't have even the video. My patch
adds the same option for the audio part of saa, just as you said above.
So I think my patch does exactly what you want. Are there any technical
problems with it? I guess not since the patch is very simple and mainly
is a copy/paste from the tuner-core.c, but you never know

Hey guys! Patch is really works!!! I had the same problem with SECAM sound
and it was solved with this patch! Is there any other "right" way to do it?

Hi,

Stas Sergeev wrote:
Hi.

Hartmut Hackmann wrote:

>Maybe we should allow to set the full standard through the application
>but this list is long. I.e. there is not only a SECAM D but also a PAL D.

Yes, but at the end the user *have* to select the standard,
one way or another. The list may be long, but seeing it entirely
in the tvtime gui, or choosing the wrong one in gui and then using
the "magic strings" to force the right one - what is more confusing?
Btw, I still don't understand why I select PAL in tvtime rather than
SECAM to get secam=d working - is this not a bug?

The video section automatically distinguishes between PAL. SECAM and NTSC.
There are means to force it but this makes little sense and just makes
the standard list longer
I rarely used tvtime in the past. Right now i can't tell why you can't
select SECAM.

>these B-G-D-K letters specify 2 things:
>- Sound IF frequencies and modulation
>- Video IF, modulation and channel width.
>So part of the information needs to go to the IF chip, i.e. the TDA9886.

Yes, that's what the "tuner" option does. It goes to TDA9887 (not 9886
btw :)

The chip physically is a tda9886 in 90% of the cases

and gives me the right video. So the option apparently works as expected.

For the video, only system M and L make a difference.

>The other part can go to the audio section of the saa713x to reduce the
>search range for the sound standard.

Which is exactly what my patch implements. So what are the concerns?

The major point is that this option MUST go to the tuner module. This can be
done with a client call. It can additionally reduce the standard search list
for the sound section of the saa713x. BTW: This is different for SAA7134 and
SAA7131/33/35.

>I need to investigate whether the standard fixup is complete for the
>moved tda9886 code.

I am sure it is. Before the tda9887 code was moved, I used that option
for "tda9887" and it used to give me video and no sound. Now, as it was

This is new for me. I expected that it previously worked

moved, I use that option for "tuner" and again it gives me the video and
not the sound. So I am quite sure that option works as expected and goes
to tda9887 very well, otherwise I wouldn't have even the video. My patch
adds the same option for the audio part of saa, just as you said above.
So I think my patch does exactly what you want. Are there any technical
problems with it? I guess not since the patch is very simple and mainly
is a copy/paste from the tuner-core.c, but you never know

At least, there is some additional work, most probably for me.
- Does it go to the tuner?
- Make this work for both, 34 and 33/35
- check and reduce the impact on the standard variants.
This is the main part of the work. Many countries have 2 sound systems:
standard sound line FM for mono and a second advanced sound system
like A2, NICAM, BTSC. This needs to be handled somehow

Best regards
Hartmut

Hello.

Hayova wrote:
Hey guys! Patch is really works!!! I had the same problem with SECAM sound
and it was solved with this patch!
Thanks for testing. :)

Is there any other "right" way to do it?
I guess no. I was looking for such a way for very long, as
well as asking in that list (got the reply that the problem
is known). So I don't think any other solutions exist right
now, and the patch will have to be updated too, so some
patience is still a due

Hello.

Hartmut Hackmann wrote:
The video section automatically distinguishes between PAL. SECAM and NTSC.
There are means to force it but this makes little sense and just makes
the standard list longer
Why this makes little sense if some people (me) need it? :)

The major point is that this option MUST go to the tuner module. This can be
Yes, that's clear enough, thanks. I was thinking about this too, but
haven't found the way to do that (not because the way didn't exist, but
because I am unfamiliar with that code).

done with a client call.
I'll try that as soon as I am back from the vacations.
I won't be able to contribute to that thread for some time now, btw.

It can additionally reduce the standard search list
for the sound section of the saa713x.
But I guess my patch exactly reduces that search list (to the single
item mostly).

>I am sure it is. Before the tda9887 code was moved, I used that option
>for "tda9887" and it used to give me video and no sound. Now, as it was
This is new for me. I expected that it previously worked
Yes, it never worked for sound, that's the problem. I actually waited
way too long for someone else to fix it. :)

At least, there is some additional work, most probably for me.
- Does it go to the tuner?
- Make this work for both, 34 and 33/35
- check and reduce the impact on the standard variants.
This is the main part of the work. Many countries have 2 sound systems:
standard sound line FM for mono and a second advanced sound system
like A2, NICAM, BTSC. This needs to be handled somehow
Yes, very probably. In fact (sorry for not saying that before), I have
2 channels (out of 15) that work even without the patch. According to the
log, they use NICAM. However, my patch doesn't break them either. For
some reasons they work with the forced secam-dk too.
Would be very nice if you do whatever you outlined above. :) I'll try
to only code up the first point (about tuner), but much later.

Hi,

Stas Sergeev wrote:
Hello.

Hartmut Hackmann wrote:

>The video section automatically distinguishes between PAL. SECAM and
>NTSC.
>There are means to force it but this makes little sense and just makes
>the standard list longer

Why this makes little sense if some people (me) need it? :)

You don't, trust me. There is no case known where forcing the video standard
was necessary under real life conditions. But there might be confusion
regarding option names

>The major point is that this option MUST go to the tuner module. This
>can be

Yes, that's clear enough, thanks. I was thinking about this too, but
haven't found the way to do that (not because the way didn't exist, but
because I am unfamiliar with that code).

>done with a client call.

I'll try that as soon as I am back from the vacations.
I won't be able to contribute to that thread for some time now, btw.

>It can additionally reduce the standard search list
>for the sound section of the saa713x.

But I guess my patch exactly reduces that search list (to the single
item mostly).
>
It does. But there are still search lists necessary for the variants of
each country. These need to be built.

I am sure it is. Before the tda9887 code was moved, I used that option
for "tda9887" and it used to give me video and no sound. Now, as it was
>>
>This is new for me. I expected that it previously worked

Yes, it never worked for sound, that's the problem. I actually waited
way too long for someone else to fix it. :)

I can imagine! But sorry, i do this in my spare time and for personal
reasons, i focused on DVB-T. And of corseit is difficult to test for the
various standards (a ton of equipment needed).

>At least, there is some additional work, most probably for me.
>- Does it go to the tuner?
>- Make this work for both, 34 and 33/35
>- check and reduce the impact on the standard variants.
>This is the main part of the work. Many countries have 2 sound systems:
>standard sound line FM for mono and a second advanced sound system
>like A2, NICAM, BTSC. This needs to be handled somehow

Yes, very probably. In fact (sorry for not saying that before), I have
2 channels (out of 15) that work even without the patch. According to the
log, they use NICAM. However, my patch doesn't break them either. For
some reasons they work with the forced secam-dk too.
Would be very nice if you do whatever you outlined above. :) I'll try
to only code up the first point (about tuner), but much later.

No problem. This hopefully gives me time to investigate the existing code
and to decide what is needed to complete your proposal.

Hartmut

Hi,

Hartmut Hackmann wrote:
>Why this makes little sense if some people (me) need it? :)
You don't, trust me. There is no case known where forcing the video standard
was necessary under real life conditions. But there might be confusion
regarding option names
K, then could you please set me straight? To get the video
working, I need to set secam=d, isnt this a video standard forcing?
And I really don't want to do this - why wouldn't it be possible to
select the exact standard from userspace?

The major point is that this option MUST go to the tuner module.
K, honestly, after spending a few hours looking at the code, I
see exactly no way to do that. To make the matters worse, it seems
like the saa module doesn't have a dependancies on the tuner module,
so the load order is unspecified (saa module can be loaded before
the tuner module).
some hacks are possible, like exporting the relevant modparams
globally, but this is out of question I suppose. Could you please hint
me on this? Actually, my idea is to get rid of that modparams completely
and make everything controllable from userspace. Would it be feasible?

>But I guess my patch exactly reduces that search list (to the single
>item mostly).
It does. But there are still search lists necessary for the variants of
each country. These need to be built.
I will work this out as soon as I get an idea on the modparams stuff.

>Yes, it never worked for sound, that's the problem. I actually waited
>way too long for someone else to fix it. :)
I can imagine! But sorry, i do this in my spare time and for personal
AFAIK there were some people working exactly on improving the AverTV
support for Russia, but I think they have failed. :(

No problem. This hopefully gives me time to investigate the existing code
and to decide what is needed to complete your proposal.
Any progress? :) The fact is that I have to reboot to Windows in order
to use my tuner, so I am getting desperate on that issue. :)
(well, as soon as my patch works for me - not any more. but still I'd
like to have that resolved once and for all)
In fact, I think if the proper solution can't be found in a short run,
my patch must be applied. It isn't perfect, but its better than nothing,
you know, and it "just works".

Hi,

Stas Sergeev wrote:
Hi,

Hartmut Hackmann wrote:

Why this makes little sense if some people (me) need it? :)
>>
>You don't, trust me. There is no case known where forcing the video
>standard
>was necessary under real life conditions. But there might be confusion
>regarding option names

K, then could you please set me straight? To get the video
working, I need to set secam=d, isnt this a video standard forcing?
And I really don't want to do this - why wouldn't it be possible to
select the exact standard from userspace?

It isn't. Actually it doesn't matter whether you select PAL or SECAM, the
important thing is the "D". And this is for the RF domain and the sound
coding. True multistandard tuners are new, the original idea was not to
let the user bother with tv standards.
But this might be necessary for the future.

The major point is that this option MUST go to the tuner module.

K, honestly, after spending a few hours looking at the code, I
see exactly no way to do that. To make the matters worse, it seems
like the saa module doesn't have a dependancies on the tuner module,
so the load order is unspecified (saa module can be loaded before
the tuner module).

Indeed. This is something i really don't like since it causes initialization
problems - especially with hybrid cards. But this is another issue.

some hacks are possible, like exporting the relevant modparams
globally, but this is out of question I suppose. Could you please hint
me on this? Actually, my idea is to get rid of that modparams completely
and make everything controllable from userspace. Would it be feasible?

I need to have a look. This should be done with a so-called client call.
If it doesn't exists, it needs to be defined.

But I guess my patch exactly reduces that search list (to the single
item mostly).
>>
>It does. But there are still search lists necessary for the variants of
>each country. These need to be built.

I will work this out as soon as I get an idea on the modparams stuff.

Yes, it never worked for sound, that's the problem. I actually waited
way too long for someone else to fix it. :)
>>
>I can imagine! But sorry, i do this in my spare time and for personal

AFAIK there were some people working exactly on improving the AverTV
support for Russia, but I think they have failed. :(

>No problem. This hopefully gives me time to investigate the existing code
>and to decide what is needed to complete your proposal.

Any progress? :) The fact is that I have to reboot to Windows in order
to use my tuner, so I am getting desperate on that issue. :)
(well, as soon as my patch works for me - not any more. but still I'd
like to have that resolved once and for all)
In fact, I think if the proper solution can't be found in a short run,
my patch must be applied. It isn't perfect, but its better than nothing,
you know, and it "just works".

Meanwhile i had a look at the saa7134 documentation. The problem seems to be
how to detect the primary standard. For the extensions, things seem to be
easier.If i can't find a way to improve this soon, i will pick up your patch
and complete it. But this is some days of work.
And as you said: I'd like to have this solved "once and for all".

Hartmut

Hi.

Hartmut Hackmann wrote:
It isn't. Actually it doesn't matter whether you select PAL or SECAM, the
important thing is the "D".
Hmm, interesting. Then the question: there is a "PAL-D/K NICAM"
defined in tvaudio[], but not "SECAM-D/K NICAM". Is this right,
or the definition should be added? Because be it there, with my
patch I would still be able to use nicam, while right now I can't.

I need to have a look. This should be done with a so-called client call.
If it doesn't exists, it needs to be defined.
I wasn't able to find out how. It looks like the tuner module
doesn't share any common structures with the saa module, except
those i2c ones that can't be changed. Also considering the
unspecified load order, I think the client call is not possible.
(or at least will require much more work than it should and
will require a modifications in all clients)

Meanwhile i had a look at the saa7134 documentation. The problem seems to be
how to detect the primary standard. For the extensions, things seem to be
easier.If i can't find a way to improve this soon, i will pick up your patch
and complete it. But this is some days of work.
And as you said: I'd like to have this solved "once and for all".
K, I'm looking forward for that. :) Next challenge for me would be
to find out how to get the sound also from the radio part of the board

, 31/07/2006 17:37 +0400, Stas Sergeev :
Hi.

Hartmut Hackmann wrote:
It isn't. Actually it doesn't matter whether you select PAL or SECAM, the
important thing is the "D".
Hmm, interesting. Then the question: there is a "PAL-D/K NICAM"
defined in tvaudio[], but not "SECAM-D/K NICAM". Is this right,
or the definition should be added? Because be it there, with my
patch I would still be able to use nicam, while right now I can't.

I need to have a look. This should be done with a so-called client call
If it doesn't exists, it needs to be defined.
I wasn't able to find out how. It looks like the tuner module
doesn't share any common structures with the saa module, except
those i2c ones that can't be changed. Also considering the
unspecified load order, I think the client call is not possible.
(or at least will require much more work than it should and
will require a modifications in all clients)

Meanwhile i had a look at the saa7134 documentation. The problem seems to be
how to detect the primary standard. For the extensions, things seem to be
easier.If i can't find a way to improve this soon, i will pick up your patch
and complete it. But this is some days of work.
And as you said: I'd like to have this solved "once and for all".
K, I'm looking forward for that. :) Next challenge for me would be
to find out how to get the sound also from the radio part of the board

Hello Hartmut and Stas and all.

It's rather interesting discussion, but let me interrupt you a bit, for
now I don't see the reason of the problem except quite hackish patch.
Secam-d is used to work some time ago, it was broken for a little period
of time but now it should work as well.

Why the patch is needed? Stas, can you describe the problem more
precisely and paste here the log of tunning on some channel with
audio_debug=9?

Hi, Nickolay

Nickolay V. Shmyrev wrote:
<snip>

Hello Hartmut and Stas and all.

It's rather interesting discussion, but let me interrupt you a bit, for
now I don't see the reason of the problem except quite hackish patch.
Secam-d is used to work some time ago, it was broken for a little period
of time but now it should work as well.

Why the patch is needed? Stas, can you describe the problem more
precisely and paste here the log of tunning on some channel with
audio_debug=9?

There basically are 2 issues
- The current SAA7134 code does not detect the primary sound standard
well. So the situation can occur that the chip does not detect a
system D sound carrier (6.5 MHz FM) and falls back to the default -
not absolutely sure but should be system B/G (5.5 MHz FM). The result
is no sound.
Stas basically proposes to force this in the application. That's possible
of corse but i dislike it because many users won't know and there are so
many possible variants - especially regarding the extended sound standard.
- The second issue is that in some cases the tuner module needs to be
informed about the tv system. This at least is the case for the systems
M, L and all the others. This currently is an insmod option for tuner.ko.
It might be a good idea to select this in user space - especially in
countries where incompatible systems can be received, i.e Belgium and
some parts of Germany.

I would prefer to separate these things.
- First try to improve the sound standard detection. If this is successful,
the user won't need to bother with the tv systems, the driver handles this
automatically except there is a multistandard tuner and system L or M.
- Multi standard tuners will become more common. We really should consider
to make the system selectable from user space. This could be used to speed
up the sound detection or make it safer as well.
But expecally from my latest experiences with DVB-T, i would prefer to
have an automatic standard detection as long as it is posible.

This is my summary.
Hartmut

Hi,

Stas Sergeev wrote:
Hi.

Hartmut Hackmann wrote:

>It isn't. Actually it doesn't matter whether you select PAL or SECAM, the
>important thing is the "D".

Hmm, interesting. Then the question: there is a "PAL-D/K NICAM"
defined in tvaudio[], but not "SECAM-D/K NICAM". Is this right,
or the definition should be added? Because be it there, with my
patch I would still be able to use nicam, while right now I can't.

This exactly is what i worried about. I guess the answer is yes. But
things look like there is an elegant solution for this. Let me investigate.

>I need to have a look. This should be done with a so-called client call.
>If it doesn't exists, it needs to be defined.

I wasn't able to find out how. It looks like the tuner module
doesn't share any common structures with the saa module, except
those i2c ones that can't be changed. Also considering the
unspecified load order, I think the client call is not possible.
(or at least will require much more work than it should and
will require a modifications in all clients)

It is posible to add client calls. The module load order issue should
not be a problem here.

>Meanwhile i had a look at the saa7134 documentation. The problem seems
>to be
>how to detect the primary standard. For the extensions, things seem to be
>easier.If i can't find a way to improve this soon, i will pick up your
>patch
>and complete it. But this is some days of work.
>And as you said: I'd like to have this solved "once and for all".

K, I'm looking forward for that. :) Next challenge for me would be
to find out how to get the sound also from the radio part of the board

Whats your exact board type? which tuner is on your board?

I gave a summary of our discussion, i hope you can agree to it.

Best regards
Hartmut

, 31/07/2006 23:58 +0200, Hartmut Hackmann :
Hi, Nickolay

Nickolay V. Shmyrev wrote:
<snip>

Hello Hartmut and Stas and all.

It's rather interesting discussion, but let me interrupt you a bit, for
now I don't see the reason of the problem except quite hackish patch.
Secam-d is used to work some time ago, it was broken for a little period
of time but now it should work as well.

Why the patch is needed? Stas, can you describe the problem more
precisely and paste here the log of tunning on some channel with
audio_debug=9?

There basically are 2 issues
- The current SAA7134 code does not detect the primary sound standard
well. So the situation can occur that the chip does not detect a
system D sound carrier (6.5 MHz FM) and falls back to the default -
not absolutely sure but should be system B/G (5.5 MHz FM). The result
is no sound.

We know that's purely tuner problem, during autodetection process we
should try to setup standard on a multi-standard tuner as well on
saa7134. I wonder if someone should try it and how much this will slow
up detection process. We should just add a client call into
tvaudio_checkcarrier or in tvaudio_thread. This won't work for saa7135
at all and I it would be very interesting to know, how saa7135 should
handle this. Will just post-fact setup of detected std work? Should we
run similar thread for audio detection? If standard on tuner is set
correctly, saa7134 does detect D vs B/G vs NICAM.

Btw, the issue of detection speed is critical here. Many users don't
want to spend a second on a channel switch just because we want to show
how we can detect sound carrier. We should allow them select correct
standard and bypass the detection.

Stas basically proposes to force this in the application. That's possible
of corse but i dislike it because many users won't know and there are so
many possible variants - especially regarding the extended sound standard.
- The second issue is that in some cases the tuner module needs to be
informed about the tv system. This at least is the case for the systems
M, L and all the others. This currently is an insmod option for tuner.ko.
It might be a good idea to select this in user space - especially in
countries where incompatible systems can be received, i.e Belgium and
some parts of Germany.

I don't understand why we can't give application acess to standard
selection in saa7134 and give them access to select standard in tuner.
To be unified with others, say with cx88 we should just let them choose
any standard they like (SECAM if the don't know anything about audio and
want to detect it, SECAM-D and SECAM-L if the wants to make detection
faster and correct it)

I would prefer to separate these things.
- First try to improve the sound standard detection. If this is successful,
the user won't need to bother with the tv systems, the driver handles this
automatically except there is a multistandard tuner and system L or M.
- Multi standard tuners will become more common. We really should consider
to make the system selectable from user space. This could be used to speed
up the sound detection or make it safer as well.
But expecally from my latest experiences with DVB-T, i would prefer to
have an automatic standard detection as long as it is posible.

Let me propose my list:
- Add SECAM-L/SECAM-DK to the saa7134_tvnorm_tvnorms in saa7134_video.c
like in cx88, apps should have access to such norms. Sadly tvtime won't
be able to choose, but I hope it will be implemented soon.
- Try to find the real problem Stas is talking about. I don't think it's
related to multituner issues since he have secam=d. We should have
debugging log first. It may be bug in tvaudio_thread that makes
detection broken.
- Experiment with standard detection on multi-standard tuner and drop
tuner secam=d option. From my experience on Avermedia in Windows drivers
already have SECAM-DK setup in channels list, so I wonder if detection
is possible at all.

This is my summary.
Hartmut

Hello.

Nickolay V. Shmyrev wrote:
Why the patch is needed?
Wasn't it you who told me a year ago that the problem
is known? :)

Secam-d is used to work some time ago, it was broken for a little period
of time but now it should work as well.
What is now? I am testing on 2.6.18-rc2-mm1.
As for used to work before - well, this is very
questionable. Yes, it used to work sometimes, i.e.
I could get sound by switching to the same channel
for 3-10 times, and now it doesn't work completely.
But reverting to the old state won't help. Switching
the channels over and over until you suddenly get sound,
was very annoying. For that I'd say, it never worked before.

Stas, can you describe the problem more
precisely and paste here the log of tunning on some channel with
audio_debug=9?
K, problem: sound works on the RT channel, which
uses nicam. do not work.
Log is attached. As you can see, first it takes
SECAM-L NICAM, as it was RT. Then I switch to other
channels, and it takes SECAM-L MN, which doesn't work.

Aug 1 15:01:27 lin2 kernel: saa7130/34: v4l2 driver version 0.2.14 loaded
Aug 1 15:01:27 lin2 kernel: saa7134[0]: found at 0000:01:08.0, rev: 1, irq: 16, latency: 32, mmio: 0xf2001000
Aug 1 15:01:27 lin2 kernel: saa7134[0]: subsystem: 1461:9715, board: Avermedia AVerTV Studio 307 [card=45,autodetected]
Aug 1 15:01:27 lin2 kernel: saa7134[0]: board init: gpio is 7cc
Aug 1 15:01:27 lin2 kernel: input: saa7134 IR (Avermedia AVerTV St as /class/input/input5
Aug 1 15:01:27 lin2 kernel: tuner 2-0043: chip found @ 0x86 (saa7134[0])
Aug 1 15:01:27 lin2 kernel: tda9887 2-0043: tda988[5/6/7] found @ 0x43 (tuner)
Aug 1 15:01:27 lin2 kernel: tuner 2-0061: chip found @ 0xc2 (saa7134[0])
Aug 1 15:01:27 lin2 kernel: tuner 2-0061: type set to 51 (Philips PAL/SECAM_D (FM 1256 I-H3))
Aug 1 15:01:27 lin2 kernel: saa7134[0]: i2c eeprom 00: 61 14 15 97 ff ff ff ff ff ff ff ff ff ff ff ff
Aug 1 15:01:27 lin2 kernel: saa7134[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Aug 1 15:01:27 lin2 kernel: saa7134[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Aug 1 15:01:27 lin2 kernel: saa7134[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Aug 1 15:01:27 lin2 kernel: saa7134[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Aug 1 15:01:27 lin2 kernel: saa7134[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Aug 1 15:01:27 lin2 kernel: saa7134[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Aug 1 15:01:27 lin2 kernel: saa7134[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Aug 1 15:01:27 lin2 kernel: saa7134[0]/audio: ctl_mute=1 automute=0 input=Television =mute=1 input=mute
Aug 1 15:01:27 lin2 kernel: saa7134[0]/audio: mute/input: nothing to do [mute=1,input=mute]
Aug 1 15:01:27 lin2 kernel: saa7134[0]: registered device video0 [v4l2]
Aug 1 15:01:27 lin2 kernel: saa7134[0]: registered device vbi0
Aug 1 15:01:27 lin2 kernel: saa7134[0]: registered device radio0
Aug 1 15:01:27 lin2 kernel: saa7134[0]/audio: mute/input: nothing to do [mute=1,input=mute]
Aug 1 15:01:27 lin2 kernel: saa7134[0]/audio: tvaudio thread scan start [1]
Aug 1 15:01:27 lin2 kernel: saa7134[0]/audio: mute/input: nothing to do [mute=1,input=mute]
Aug 1 15:01:28 lin2 kernel: [drm] Loading R300 Microcode
Aug 1 15:01:30 lin2 kernel: saa7134[0]/audio: debug 4500: 7678 7678 7678 7678 7678 # 7678 # 7678 7678 7678 7678 7678
Aug 1 15:01:30 lin2 kernel: saa7134[0]/audio: skipping 4.500 MHz [ M]
Aug 1 15:01:33 lin2 kernel: saa7134[0]/audio: debug 5500: 7678 7678 7678 7678 7678 # 7678 # 7678 7678 7678 7678 7678
Aug 1 15:01:33 lin2 kernel: saa7134[0]/audio: scanning 5.500 MHz [ BG] =dc is 0 [7678/7678]
Aug 1 15:01:34 lin2 kernel: saa7134[0]/audio: debug 6000: 7678 7678 7678 7678 7678 # 7678 # 7678<7>saa7134[0]/audio: mute/input: nothing to do [mute=1,input=mute]
Aug 1 15:01:34 lin2 kernel: saa7134[0]/audio: mute/input: nothing to do [mute=1,input=mute]
Aug 1 15:01:34 lin2 kernel: saa7134[0]/audio: tvaudio thread scan start [2]
Aug 1 15:01:34 lin2 kernel: saa7134[0]/audio: mute/input: nothing to do [mute=1,input=mute]
Aug 1 15:01:35 lin2 kernel: saa7134[0]/audio: mute/input: nothing to do [mute=1,input=mute]
Aug 1 15:01:35 lin2 kernel: saa7134[0]/audio: tvaudio thread scan start [3]
Aug 1 15:01:35 lin2 kernel: saa7134[0]/audio: mute/input: nothing to do [mute=1,input=mute]
Aug 1 15:01:35 lin2 kernel: saa7134[0]/audio: tvaudio thread scan start [4]
Aug 1 15:01:35 lin2 kernel: saa7134[0]/audio: mute/input: nothing to do [mute=1,input=mute]
Aug 1 15:01:35 lin2 kernel: saa7134[0]/audio: mute/input: nothing to do [mute=1,input=mute]
Aug 1 15:01:35 lin2 kernel: saa7134[0]/audio: tvaudio thread scan start [5]
Aug 1 15:01:35 lin2 kernel: saa7134[0]/audio: mute/input: nothing to do [mute=1,input=mute]
Aug 1 15:01:35 lin2 kernel: saa7134[0]/audio: tvaudio thread scan start [6]
Aug 1 15:01:35 lin2 kernel: saa7134[0]/audio: mute/input: nothing to do [mute=1,input=mute]
Aug 1 15:01:35 lin2 kernel: saa7134[0]/audio: mute/input: nothing to do [mute=1,input=mute]
Aug 1 15:01:36 lin2 kernel: saa7134[0]/audio: found SECAM main sound carrier @ 6.500 MHz [12345/0]
Aug 1 15:01:36 lin2 kernel: saa7134[0]/audio: ctl_mute=0 automute=0 input=Television =mute=0 input=Television
Aug 1 15:01:36 lin2 kernel: saa7134[0]/audio: tvaudio_setmode: trying SECAM-L NICAM [6.500/5.850 MHz] acpf=122880+0
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: getstereo: nicam=0x1
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: getstereo: nicam_status=0x8a
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: found audio subchannels: mono stereo
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: tvaudio_setmode: using SECAM-L NICAM [6.500/5.850 MHz] acpf=122880+0
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: setstereo [fm] =mono
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: getstereo: nicam=0x1
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: getstereo: nicam_status=0x8a
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: found audio subchannels: mono stereo
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: getstereo: nicam=0x1
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: getstereo: nicam_status=0x8a
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: found audio subchannels: mono stereo
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: getstereo: nicam=0x1
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: getstereo: nicam_status=0x8a
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: found audio subchannels: mono stereo
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: getstereo: nicam=0x1
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: getstereo: nicam_status=0x8a
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: found audio subchannels: mono stereo
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: getstereo: nicam=0x1
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: getstereo: nicam_status=0x8a
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: found audio subchannels: mono stereo
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: getstereo: nicam=0x1
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: getstereo: nicam_status=0x8a
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: found audio subchannels: mono stereo
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: ctl_mute=1 automute=0 input=Television =mute=1 input=mute
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: tvaudio thread scan start [7]
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: mute/input: nothing to do [mute=1,input=mute]
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: tvaudio thread scan start [8]
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: mute/input: nothing to do [mute=1,input=mute]
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: tvaudio thread scan start [9]
Aug 1 15:01:38 lin2 kernel: saa7134[0]/audio: mute/input: nothing to do [mute=1,input=mute]
Aug 1 15:01:38 lin2 last message repeated 2 times
Aug 1 15:01:39 lin2 kernel: saa7134[0]/audio: tvaudio thread scan start [10]
Aug 1 15:01:39 lin2 kernel: saa7134[0]/audio: mute/input: nothing to do [mute=1,input=mute]
Aug 1 15:01:40 lin2 kernel: saa7134[0]/audio: found SECAM main sound carrier @ 6.500 MHz [12345/0]
Aug 1 15:01:40 lin2 kernel: saa7134[0]/audio: ctl_mute=0 automute=0 input=Television =mute=0 input=Television
Aug 1 15:01:40 lin2 kernel: saa7134[0]/audio: tvaudio_setmode: trying SECAM-L NICAM [6.500/5.850 MHz] acpf=122880+0
Aug 1 15:01:42 lin2 kernel: saa7134[0]/audio: getstereo: nicam=0x2
Aug 1 15:01:42 lin2 kernel: saa7134[0]/audio: tvaudio_setmode: trying SECAM-L MN [6.500/0.-01 MHz] acpf=122880+0
Aug 1 15:01:43 lin2 kernel: saa7134[0]/audio: ctl_mute=1 automute=0 input=Television =mute=1 input=mute
Aug 1 15:01:43 lin2 kernel: saa7134[0]/audio: tvaudio thread scan start [11]
Aug 1 15:01:43 lin2 kernel: saa7134[0]/audio: mute/input: nothing to do [mute=1,input=mute]
Aug 1 15:01:43 lin2 kernel: saa7134[0]/audio: tvaudio thread scan start [12]
Aug 1 15:01:43 lin2 kernel: saa7134[0]/audio: mute/input: nothing to do [mute=1,input=mute]
Aug 1 15:01:43 lin2 kernel: saa7134[0]/audio: tvaudio thread scan start [13]
Aug 1 15:01:43 lin2 kernel: saa7134[0]/audio: mute/input: nothing to do [mute=1,input=mute]
Aug 1 15:01:43 lin2 last message repeated 2 times
Aug 1 15:01:43 lin2 kernel: saa7134[0]/audio: tvaudio thread scan start [14]
Aug 1 15:01:43 lin2 kernel: saa7134[0]/audio: mute/input: nothing to do [mute=1,input=mute]
Aug 1 15:01:44 lin2 kernel: saa7134[0]/audio: found SECAM main sound carrier @ 6.500 MHz [12345/0]
Aug 1 15:01:44 lin2 kernel: saa7134[0]/audio: ctl_mute=0 automute=0 input=Television =mute=0 input=Television
Aug 1 15:01:44 lin2 kernel: saa7134[0]/audio: tvaudio_setmode: trying SECAM-L NICAM [6.500/5.850 MHz] acpf=122880+0
Aug 1 15:01:46 lin2 kernel: saa7134[0]/audio: getstereo: nicam=0x2
Aug 1 15:01:46 lin2 kernel: saa7134[0]/audio: tvaudio_setmode: trying SECAM-L MN [6.500/0.-01 MHz] acpf=122880+0
Aug 1 15:01:46 lin2 kernel: saa7134[0]/audio: ctl_mute=1 automute=0 input=Television =mute=1 input=mute
Aug 1 15:01:46 lin2 kernel: saa7134[0]/audio: tvaudio thread scan start [15]
Aug 1 15:01:46 lin2 kernel: saa7134[0]/audio: mute/input: nothing to do [mute=1,input=mute]
Aug 1 15:01:46 lin2 last message repeated 2 times
Aug 1 15:01:47 lin2 kernel: saa7134[0]/audio: tvaudio thread scan start [16]
Aug 1 15:01:47 lin2 kernel: saa7134[0]/audio: mute/input: nothing to do [mute=1,input=mute]
Aug 1 15:01:48 lin2 kernel: saa7134[0]/audio: found SECAM main sound carrier @ 6.500 MHz [12345/0]
Aug 1 15:01:48 lin2 kernel: saa7134[0]/audio: ctl_mute=0 automute=0 input=Television =mute=0 input=Television
Aug 1 15:01:48 lin2 kernel: saa7134[0]/audio: tvaudio_setmode: trying SECAM-L NICAM [6.500/5.850 MHz] acpf=122880+0
Aug 1 15:01:50 lin2 kernel: saa7134[0]/audio: getstereo: nicam=0x2
Aug 1 15:01:50 lin2 kernel: saa7134[0]/audio: tvaudio_setmode: trying SECAM-L MN [6.500/0.-01 MHz] acpf=122880+0
Aug 1 15:01:50 lin2 kernel: saa7134[0]/audio: ctl_mute=1 automute=0 input=Television =mute=1 input=mute
Aug 1 15:01:52 lin2 kernel: saa7134[0]/audio: tvaudio_setmode: using SECAM-L MN [6.500/0.-01 MHz] acpf=122880+0

Hello.

Hartmut Hackmann wrote:
>K, I'm looking forward for that. :) Next challenge for me would be
>to find out how to get the sound also from the radio part of the board
Whats your exact board type? which tuner is on your board?
I posted the log in the nearby message - that info
should be there. But I wouldn't mix also the radio
issues in that thread. When the video problems are
resolved, I'll post back with that too.
A quick description however:
- Radio used to work a year ago.
- Then the channel detection was broken, so the manual
searching became a due.
- Then and till now - no sound at all.
So it erroded slowly and spectacularly.

This part I don't understand:

Aug 1 15:01:48 lin2 kernel: saa7134[0]/audio: ctl_mute=0 automute=0
input=Television =mute=0 input=Television
Aug 1 15:01:48 lin2 kernel: saa7134[0]/audio: tvaudio_setmode: trying
SECAM-L NICAM [6.500/5.850 MHz] acpf=122880+0
Aug 1 15:01:50 lin2 kernel: saa7134[0]/audio: getstereo: nicam=0x2
Aug 1 15:01:50 lin2 kernel: saa7134[0]/audio: tvaudio_setmode: trying
SECAM-L MN [6.500/0.-01 MHz] acpf=122880+0
Aug 1 15:01:50 lin2 kernel: saa7134[0]/audio: ctl_mute=1 automute=0
input=Television =mute=1 input=mute
Aug 1 15:01:52 lin2 kernel: saa7134[0]/audio: tvaudio_setmode: using
SECAM-L MN [6.500/0.-01 MHz] acpf=122880+0

Either it's outdated sources (btw, it would be nice if you'll test recent v4l-dvb instead
of kernel) or it's something wrong in application. It should scan for secam-dk as well,
I don't know why it fallback to secam-l. The easies way is to debug this situation. Look
at the following loop in saa7134-tvaudio:

/* find the exact tv audio norm */
for (audio = UNSET, i = 0; i < TVAUDI; i++) {
if (dev->tvnorm->id != UNSET &&
!(dev->tvnorm->id & tvaudio[i].std))
continue;
if (tvaudio[i].carr1 != carrier)
continue;

if (UNSET == audio)
audio = i;
tvaudio_setmode(dev,&tvaudio[i],"trying");
if (tvaudio_sleep(dev,SCAN_SUBCARRIER_DELAY))
goto restart;
if (-1 != tvaudio_getstereo(dev,&tvaudio[i])) {
audio = i;
break;
}
}

Can you debug it and find the reason it stops after SECAM-L mono? As I understand tvaudio_getstereo returns -1 as well in this case (otherwise it will write about nicam status). Why in your case SECAM-DK scan is skipped?

Nickolay V. Shmyrev wrote:
, 31/07/2006 23:58 +0200, Hartmut Hackmann :

>>Hi, Nickolay
>>
>>Nickolay V. Shmyrev wrote:
>><snip>
>>
Hello Hartmut and Stas and all.

It's rather interesting discussion, but let me interrupt you a bit, for
now I don't see the reason of the problem except quite hackish patch.
Secam-d is used to work some time ago, it was broken for a little period
of time but now it should work as well.

Why the patch is needed? Stas, can you describe the problem more
precisely and paste here the log of tunning on some channel with
audio_debug=9?

>>
>>There basically are 2 issues
The current SAA7134 code does not detect the primary sound standard
>well. So the situation can occur that the chip does not detect a
>system D sound carrier (6.5 MHz FM) and falls back to the default -
>not absolutely sure but should be system B/G (5.5 MHz FM). The result
>is no sound.

We know that's purely tuner problem, during autodetection process we
should try to setup standard on a multi-standard tuner as well on
saa7134. I wonder if someone should try it and how much this will slow
up detection process. We should just add a client call into
tvaudio_checkcarrier or in tvaudio_thread. This won't work for saa7135
at all and I it would be very interesting to know, how saa7135 should
handle this. Will just post-fact setup of detected std work? Should we
run similar thread for audio detection? If standard on tuner is set
correctly, saa7134 does detect D vs B/G vs NICAM.

I heard more than one complaint about the sound detection but these might
all come from the same direction. Stas log pointed me to the problem:
If we use ony information from the sound (and video) processing: How do we
distinguish SECAM-D from SECAM-L? Both have 6.5MHz primary sound carrier,
both have the same secondary carrier with NICAM. But for primary sound,
L uses AM and D uses FM. This can't be reliable.
I guess this is the problem, see below.
Post fact setup can only work under some circumstances:
It should be possible for G,H,I,D and K, some doubt about B but definitely
not for M, N and L. M and N not. This is due to the significantly lower
channel bandwidth for M and N and die different video modulation of L
( even the video won't lock).

Btw, the issue of detection speed is critical here. Many users don't
want to spend a second on a channel switch just because we want to show
how we can detect sound carrier. We should allow them select correct
standard and bypass the detection.

Indeed. SAA7133 and 35 already have a means to reduce the search list,
but this is rarely known.

>Stas basically proposes to force this in the application. That's possible
>of corse but i dislike it because many users won't know and there are so
>many possible variants - especially regarding the extended sound standard.
>>
The second issue is that in some cases the tuner module needs to be
>informed about the tv system. This at least is the case for the systems
>M, L and all the others. This currently is an insmod option for tuner.ko.
>It might be a good idea to select this in user space - especially in
>countries where incompatible systems can be received, i.e Belgium and
>some parts of Germany.
>>

I don't understand why we can't give application acess to standard
selection in saa7134 and give them access to select standard in tuner.
To be unified with others, say with cx88 we should just let them choose
any standard they like (SECAM if the don't know anything about audio and
want to detect it, SECAM-D and SECAM-L if the wants to make detection
faster and correct it)

I know almost nothing about cx88 but saa713x does a pretty good job on
automatic video standard detection. Distinguishing between PAL and SECAM
just gives little more freedom for video parameter tuning - hardly worth it.
But see below.

>>I would prefer to separate these things.
First try to improve the sound standard detection. If this is successful,
>the user won't need to bother with the tv systems, the driver handles this
>automatically except there is a multistandard tuner and system L or M.
Multi standard tuners will become more common. We really should consider
>to make the system selectable from user space. This could be used to speed
>up the sound detection or make it safer as well.
>But expecally from my latest experiences with DVB-T, i would prefer to
>have an automatic standard detection as long as it is posible.

Let me propose my list:
- Add SECAM-L/SECAM-DK to the saa7134_tvnorm_tvnorms in saa7134_video.c
like in cx88, apps should have access to such norms. Sadly tvtime won't
be able to choose, but I hope it will be implemented soon.

From the above, adding (SECAM)-L would help to solve the problem. This must be
set manually anyway.
From saa713x view only, it does not make to add more, its just a new chance for
the user to make mistakes.
But from sound and tuner point of view, it makes sense to add all RF variants.
This could be used to make sound detection faster, helps with multi standard
tuners and would also give a solution where tda9886 does the sound demodulation
(i.e. with saa7130).
But will the user understand this?
- Try to find the real problem Stas is talking about. I don't think it's
related to multituner issues since he have secam=d. We should have
debugging log first. It may be bug in tvaudio_thread that makes
detection broken.

I am almost convinced now that distinguishing D and L is the problem.
- Experiment with standard detection on multi-standard tuner and drop
tuner secam=d option. From my experience on Avermedia in Windows drivers
already have SECAM-DK setup in channels list, so I wonder if detection
is possible at all.

Again, D and L. But this would mean that SECAM needs to be defined manually
to get an indication of system L.

Best regards
Hartmut

Hi, Stas

Stas Sergeev wrote:
Hello.

Hartmut Hackmann wrote:

K, I'm looking forward for that. :) Next challenge for me would be
to find out how to get the sound also from the radio part of the
board
>>
>Whats your exact board type? which tuner is on your board?

I posted the log in the nearby message - that info
should be there. But I wouldn't mix also the radio
issues in that thread. When the video problems are
resolved, I'll post back with that too.
A quick description however:
- Radio used to work a year ago.
- Then the channel detection was broken, so the manual
searching became a due.
- Then and till now - no sound at all.
So it erroded slowly and spectacularly.

I assume you read my previos mail on this.
Can you please do the following:
- Get and install the recent code from linuxtv.org.
i hope this makes radio work again.
- Test again. I guess your sound problem will remain. If
yes, please remove SECAM-L from the search list. I expect that
this makes thing work for you.

Best regards
Hartmut

Am Mittwoch, den 02.08.2006, 00:25 +0200 schrieb Hartmut Hackmann:

Nickolay V. Shmyrev wrote:
, 31/07/2006 23:58 +0200, Hartmut Hackmann :

>>Hi, Nickolay
>>
>>Nickolay V. Shmyrev wrote:
>><snip>
>>
Hello Hartmut and Stas and all.

It's rather interesting discussion, but let me interrupt you a bit, for
now I don't see the reason of the problem except quite hackish patch.
Secam-d is used to work some time ago, it was broken for a little period
of time but now it should work as well.

Why the patch is needed? Stas, can you describe the problem more
precisely and paste here the log of tunning on some channel with
audio_debug=9?

>>
>>There basically are 2 issues
The current SAA7134 code does not detect the primary sound standard
>well. So the situation can occur that the chip does not detect a
>system D sound carrier (6.5 MHz FM) and falls back to the default -
>not absolutely sure but should be system B/G (5.5 MHz FM). The result
>is no sound.

We know that's purely tuner problem, during autodetection process we
should try to setup standard on a multi-standard tuner as well on
saa7134. I wonder if someone should try it and how much this will slow
up detection process. We should just add a client call into
tvaudio_checkcarrier or in tvaudio_thread. This won't work for saa7135
at all and I it would be very interesting to know, how saa7135 should
handle this. Will just post-fact setup of detected std work? Should we
run similar thread for audio detection? If standard on tuner is set
correctly, saa7134 does detect D vs B/G vs NICAM.

I heard more than one complaint about the sound detection but these might
all come from the same direction. Stas log pointed me to the problem:
If we use ony information from the sound (and video) processing: How do we
distinguish SECAM-D from SECAM-L? Both have 6.5MHz primary sound carrier,
both have the same secondary carrier with NICAM. But for primary sound,
L uses AM and D uses FM. This can't be reliable.
I guess this is the problem, see below.
Post fact setup can only work under some circumstances:
It should be possible for G,H,I,D and K, some doubt about B but definitely
not for M, N and L. M and N not. This is due to the significantly lower
channel bandwidth for M and N and die different video modulation of L
( even the video won't lock).

Btw, the issue of detection speed is critical here. Many users don't
want to spend a second on a channel switch just because we want to show
how we can detect sound carrier. We should allow them select correct
standard and bypass the detection.

Indeed. SAA7133 and 35 already have a means to reduce the search list,
but this is rarely known.

just for that one.
modinfo does all that it stays so with audio_ddep

Hermann

Hello.

Hartmut Hackmann wrote:
- Get and install the recent code from linuxtv.org.
i hope this makes radio work again.
K, I wasn't aware the drivers in -mm are that old, sorry.
Well, radio sound now works, but the signal detection still
doesn't. Automatic channel searching therefore doesn't work.
The signal indicator in gnomeradio doesn't work too.
This all used to work a year ago.
- Test again. I guess your sound problem will remain. If
yes, please remove SECAM-L from the search list. I expect that
this makes thing work for you.
This is rather obvious - I tried that also before. Removing
SECAM-L of course makes it to go down to SECAM-DK. That was
the reason behind my patch - to dynamically remove some entries
from the search list. Except that with the patch you get the
sound immediately, without a 3 seconds of noise and cracks.

Hi,

Stas Sergeev wrote:
Hello.

Hartmut Hackmann wrote:

>- Get and install the recent code from linuxtv.org.
>i hope this makes radio work again.

K, I wasn't aware the drivers in -mm are that old, sorry.
Well, radio sound now works, but the signal detection still
doesn't. Automatic channel searching therefore doesn't work.
The signal indicator in gnomeradio doesn't work too.
This all used to work a year ago.

>- Test again. I guess your sound problem will remain. If
>yes, please remove SECAM-L from the search list. I expect that
>this makes thing work for you.

This is rather obvious - I tried that also before. Removing
SECAM-L of course makes it to go down to SECAM-DK. That was
the reason behind my patch - to dynamically remove some entries
from the search list. Except that with the patch you get the
sound immediately, without a 3 seconds of noise and cracks.

Did you mention this before? Sorry, i don't think its obvious if
you can't test it yourself and just need to work with the standard
tables
Anyway: now we know what is going wrong and can work on a clean
solution.

Hartmut

Hi,

Am Mittwoch, den 02.08.2006, 14:29 +0400 schrieb Stas Sergeev:
Hello.

Hartmut Hackmann wrote:
- Get and install the recent code from linuxtv.org.
i hope this makes radio work again.
K, I wasn't aware the drivers in -mm are that old, sorry.
Well, radio sound now works, but the signal detection still
doesn't. Automatic channel searching therefore doesn't work.
The signal indicator in gnomeradio doesn't work too.
This all used to work a year ago.

we had a working stereo detection taken from the tuner, which the apps
treated like signal detection, still works fine for me with a nominal
signal of 50% and e.g. kradio. Signal detection would have to be
implemented on the tda9887 itself looping through afc narrow down
routines in FM low sensitivity mode. That roughly is the suggested
patent pending method, IIRC.

Including Mauro's test repo for merging the tda9887 to tuner I didn't
notice something obviously changed to worse on FM1216ME/I MK3 radio.
That was later with FM automute off. We had it previously also off when
we had mono only, but these times no such annoyance like now.

I must annotate that I don't trust my hardware fully currently, since I
had prior suddenly an formerly never seen issue.
After using radio dark colours in TV, which went away with a different
mobo and PSU later. Might have been voltage problems on the older stuff,
but can't exclude such on the card itself, especially as nobody else
reported any similar issues.

So, for the records, as with the default settings of the mercurial from
today the radio is hardly usable anymore on the md7134. After a cold
boot, not using any TV previously, a well tuned known best station has
continuously loud cracks like close to tuned to off, after that the loud
thrilling noise starts then. After some tuning this loud thrill pulses
with the basses on the good station! I escaped with port2=1 too at the
moment, never seen before. AGC noise introduced by very high tones
during silence is known.

Every reloading of the modules with defaults reproduces the crap.

What I believe to have seen previously, is a decoupling of the AGC if
the TP is set to frequently, but this here was upon a cold boot and
reloading and radio only.

I'll take it again as an issue with my hardware, until other similar
reports might come in and choose settings, which it still can stand.
- Test again. I guess your sound problem will remain. If
yes, please remove SECAM-L from the search list. I expect that
this makes thing work for you.
This is rather obvious - I tried that also before. Removing
SECAM-L of course makes it to go down to SECAM-DK. That was
the reason behind my patch - to dynamically remove some entries
from the search list. Except that with the patch you get the
sound immediately, without a 3 seconds of noise and cracks.

Cheers,
Hermann

Em Qua, 2006-08-02 14:29 +0400, Stas Sergeev escreveu:
Hello.

Hartmut Hackmann wrote:
- Get and install the recent code from linuxtv.org.
i hope this makes radio work again.
K, I wasn't aware the drivers in -mm are that old, sorry.
Drivers on latest -mm are not old, since I keep sending updating to
latest -mm frequently (but only for the newest development kernel).

Cheers,
Mauro.

Hi,

Hartmut Hackmann wrote:
>This is rather obvious - I tried that also before. Removing
>SECAM-L of course makes it to go down to SECAM-DK. That was
>the reason behind my patch - to dynamically remove some entries
>from the search list. Except that with the patch you get the
>sound immediately, without a 3 seconds of noise and cracks.
Did you mention this before? Sorry, i don't think its obvious if
you can't test it yourself and just need to work with the standard
My patch does exactly that - removes some entries from the search
list. So I guess the only new piece of information for you was the
fact that removing *only* SECAM-L is already enough, and that's
what I haven't said. But I wouldn't have said that even now, Because
it is not really enough. Removing only SECAM-L, you have the sound
after 3 seconds of noise. It is better than nothing, but still not
the way to go.

Anyway: now we know what is going wrong and can work on a clean
solution.
May I hope that the clean solution will not give me the 3 seconds
of noise before the sound to appear? :)

Well, I've managed to install latest sources and found the change that
broke DK

;style=gitweb

I certainly remember the discussion about that

Certainly it's not a wrong patch, but a fix for SECAM-L. This trouble
stays here for several years, it was broken in 2.6.11 than repaired in
2.6.12, then broken again in 2.6.17 (it's about DK, with the L situation
was the opposite).

We have to solve this somehow, I think more extensive testing is needed.
I am now reading datasheets, but probably someone know the exact
solution. Probably we should just drop that broken autodetection of
sound carrier that doesn't work properly.