Re: ATI "HDTV Wonder" audio

[CityK <cityk@rogers.com>]

Bill Davidsen wrote:
> I'm not sure what you mean by external audio

An external analog audio source that you input to the card (i.e. such as 
from a DVD player, VCR, STB, camcorder etc) .... usually used in 
conjunction with the external analog video inputs (i.e. s-video or 
composite) ..... i.e. the A/V inputs .... such input signals must be 
digitized (ADC) ... in the case of the HDTV Wonder, external analog 
video signals input to the card are handled by cx88, whereas with audio, 
the ak5355, which in turn passes the then digitized audio stream to the 
cx88.

The only other audio source for the card is from the tuner .... in the 
case of digital, the card has nothing to do with the audio itself, as 
the audio stream is embedded within the transport stream received by the 
card and which is shipped downstream for processing ... in the case of 
analog, the related sound portion of the signal is usually referred to 
as either TV- or broadcast audio. With broadcast audio, unlike in the 
case of digital, the receiver card/device has a key role -- first, the 
audio portion has to be demodulated properly into L and R channel 
baseband signals and then digitized.

[ Big sidebar / side diversion / optional  discussion starts: ]

Hermann picked up on something here, and to which I've just clued into 
again as well.  Recall that Hermann had wrote: "wondering, why has the 
TUV1236D the TDA9887_PRESENT on the saa7134 cards, but not on this one?"


- on your card (HDTV Wonder) is a a tin can receiver ( 
http://www.linuxtv.org/wiki/index.php/Philips_TUV1236D ), in which is 
embedded a TDA9887 analog IF demodulator  .... in case what is meant by 
"IF" is not clear see: 
http://www.linuxtv.org/wiki/index.php/Demodulator  and  
http://www.linuxtv.org/wiki/index.php/Frontend  (this second link is 
specific to digital, but the concepts conveyed are similar and should 
help reinforce with the understanding).

-  now, returning to the TDA9887  -- it has both V-IF (video) and S-IF 
(sound) demodulation capabilities .... from memory, I believe that it 
can handle all major broadcast audio standards (BTSC, NICAM...) 
associated with the various types of analog TV standards (NTSC, PAL, 
SECAM....)

So, at first glance, one might expect that the signal pathway is:

(i)  RF signal --> tuner IC --> IF signal --> TDA9887

But this is not the case of cards using TUV1236D & cx88 .... that's 
because the signal that would be outputted from the TDA9887 would be a 
baseband analog signal and, as alluded to earlier, the cx88 doesn't have 
facilities for handling such signals ... (the allusion was in respect to 
the inability to handle external audio sources ... specifically, such 
input sources are themselves in the form of baseband audio ... this is 
why we need the 3rd party onboard ADC (the AK5355) which in turn routes 
the digitized audio stream to the cx88 via an i2c interface ..... so, in 
the case of TV-in/broadcast audio, if the card were to follow the 
pathway steps above, it would then have to route the baseband audio to 
the AK5355 first ... and that gets messy in terms traces on the PCB etc.

The key point here is that the cx88 can perform TV-in/broadcast audio 
demodulation too (i.e. demodulation of S-IF), so, a much simpler pathway 
is given by:

(ii) RF signal --> tuner IC --> IF signal --> cx88 for S-IF demodulation 
and then ADC


On the other hand, in the case of cards using TUV1236D & saa7135, things 
aren't as limited, as the the saa7135 is capable of both handling 
baseband audio sources AND demodulation of S-IF.  So, it would seem that 
with these cards there are, theoretically,  two different, but 
legitimate, pathway choices for TV-in/broadcast audio:

(i)  RF signal --> tuner IC --> IF signal --> TDA9887  --> baseband 
signal --> saa7135 for ADC

or

(ii)  RF signal --> tuner IC --> IF signal --> baseband audio -->  
saa7135 for S-IF demodulation and then ADC

Now is the actual pathway hardwired for these cards, or can we actually 
control that aspect via the drivers ??  I don't know.  Earlier, at the 
beginning of this diversionary discussion, I said that I just clued into 
this point again because I had forgotten that I had once pondered this 
question before, but Hermann's astuteness reminded me of this  .... I 
just don't remember in what thread, or if it was on the #IRC channel,  
that I placed my enquiry about the pathway being used by TUV1236D & 
saa7135  based cards

If I'm not mistaken, I think I did so while I was investigating the 
sound sampling (ADC) capabilities with the saa7135 ... currently, the 
saa7135 Linux driver limits sampling of broadcast audio to 32KHz (the 
data sheet indicates that 48KHz is also possible, but offhand I can't 
recall the exact reason why this is not feasible; though it has been 
discussed on a number of occasions in the past).  On the other hand, the 
saa7135 should be able to sample (i.e. perform ADC on) baseband audio 
sources at either 32, 44.1, or 48KHz ... and, to the best of my 
knowledge, this later case of choice does indeed work as expected.

I'll have to think about this, and try to find that thread to which I 
posted, as I don't recall receiving a satisfactory answer ... in any 
regard, if it is not clear to what I driving at, here is the implication:

if the pathway for the broadcast audio is NOT hardwired on these cards, 
then theoretically, it boils down to a case of the driver defining which 
route to take. 

If the driver is written to use scenario (ii), which I believe is the 
case, then because of the limitations of the saa7135's S-IF demodulation 
capabilities, the end user is stuck with having to "capture"  analog 
TV-audio at 32KHz ... for those of you not familiar with the TV-audio 
capturing quality of this chip, lets just say that its less then stellar 
(i.e. tinny sounding; prone to clipping; prone to crackling and metallic 
"zing" like sounds ... turning the audio input level in the mixer down 
alleviates some of those, but they are still present). 

If the driver is written to use scenario (i), then theoretically, it 
should provide some flexibility for the end user -- i.e. choice of 
either 32, 44.1, or 48KHz sampling rates  ... the hope, in this point, 
is that one of the other sampling rates would provide better 
results/quality then as obtainable under the current situation (i.e. 
limited to 32KHz and less then stellar quality)

[ :Big sidebar / side diversion / optional  discussion ends ]


> when the card was tried in a Windows system it had sound, so there is 
> some way to get the audio "external" of the card and into the computer. 

The above description (immediately above the long-winded optional 
discussion) should bring some clarity as to what I had meant by external 
audio .... unfortunately, I see that I also used "external" again in my 
earlier message's description ... though this second case was meant in a 
different context, I do see how this could have contributed to some 
confusion. 

In any regard, lets address this second point:   "getting the audio 
external of the card"

After the cx88 has processed the broadcast audio, it has two choices of 
what to do with the audio at that point:

(i) send it through the chip's internal DAC and then route it directly 
off the card to a sound card for processing ... you'd do this via a 
loopback cable that you'd attach directly between the tv-card and sound 
card, or via an external cable between the tv-card (on the back of the 
card's riser) and an input jack on the soundcard. 

or

(ii) keep the now digital signal in the digital domain by having the 
cx88 packetize the audio bitstream and send it across the PCI bus for 
processing downstream .... attaching a label to a process, what we're 
talking about here is referred to as audio DMA.


Intuitively, route (i) sounds a little retarded -- after all, the card 
has just performed ADC on the audio, so why in the hell would you want 
to do DAC and send it off to the soundcard for another round of ADC?  
But if you said that route (i) is the norm as opposed to the exception, 
you'd also be right.

In any regard, route (i) isn't even an option for the HDTV wonder as, 
like I mentioned in the earlier message:

 CityK wrote:
> the HDTV Wonder lacks any sort of audio out (via either an internal 
> loop back cable to the sound card or similarly an external out on the 
> riser).  Therefore ... you would indeed need to use cx88-alsa,

Using cx88-alsa implies that you'd be using route (ii); the audio DMA 
route.  The situation under a Windows OS is exactly the same -- a driver 
with audio DMA capabilities must be present, else you'd receive no audio.


Bill Davidsen wrote:
> As noted in my original post, I'm using cx88_alsa,

I think that is what initially lead me to believe that you were only 
talking about an external audio source, because as far as I'm aware, 
cx88-alsa works for the HDTV wonder...but there are some other points 
about using cx88-alsa which I failed to take into consideration in your 
case (which I'll address very shortly) and prematurely jumped to the 
conclusion that you were looking to get an external audio source working 
with your card.

By the time Hermann replied, and I replied back to him, I had long 
forgotten your statement about using alsa and the fact that it was it 
(that fact in itself) which had initially lead me to formulate my 
original reply as I had.  By the time I took Hermann's observations into 
consideration, I was well along in the process of turning a clean answer 
into something very opaque.

So, having played a key part in muddying the waters, I hope that this 
reply clears them up and provides a conclusive explanation of the 
broadcast audio  facilities available on your card.

> I'm using cx88_alsa  ... I loaded the cx88_alsa module with "index=1" 
> and now /proc/asound/cards shows the internal audio as card0 and the 
> cx88 as card1. But I can't get any sound OUT of the card to play, or 
> even record. ... it just doesn't work. It's not muted, the volume is 
> up, but nothing. Why they didn't populate the soundcard out on the 
> card I don't know, all the traces are there but no socket is provided.
>
> Is it likely that "pulseaudio" stuff is the problem? This is the first 
> time I've used it with video, so I'm at least suspicious, but several 
> people warned I can't just rip it out, I may have to drop back to 
> several older things.

Linux and audio DMA with the cx88:

a) the chipset on the card has to support it ... which we already know 
is true

b) the board has to support it .... not all cx88 boards support it  ... 
if a cx88 card is going to support digital audio (i.e. audio dma), then 
you will see 1741:8801 or 1741:8811 with "lspci -n" ... if absent, 
cx88-alsa will not work with these cards.

We already know your board should do audio dma (your Windows test, for 
example proves this).  So, a "lspci -n | grep 1741" should indeed spit 
out a "8801" or "8811" answer 

c) you need a driver to support it ...  cx88-alsa ... which appears to 
be loading fine for your card.

d) you need applications that support it ... Uh-oh, here's the biggie 
.... and this is where I now suspect you are running into difficulty.

Not many viewing apps under Linux  natively support audio DMA.  Mythtv 
and mplayer do.  tvtime, xawtv etc etc don't.

- With mplayer and the cx88, you will also have to specifically use 
"norm=NTSC-M" in your cmdline argument.
- Mythtv should have an option for setting up the correct sound device 
(default is /dev/dsp ... which should be your sound card, so you'll have 
to adjust this setting for your tvcard ... i.e. likely /dev/dsp2 or 
whatever)
- with tvtime, xawtv etc, you'll have to use a helper application like 
arecord or sox before audio dma will work.

I suggest you first test with mplayer to see if its working.  Try 
something "basic" like this:

mplayer -v tv:// -tv 
driver=v4l2:norm=NTSC-M:input=0:alsa:adevice=hw.1,0:forceaudio:immediatemode=0:audiorate=48000:amode=1:width=384:height=288:outfmt=yuy2:device=/dev/video0:chanlist=us-cable:channel=7

The command is all one line, so just copy and paste it into a console.  
Note: it should be pretty generic for most systems with just one tv 
card, but if any of the parameters listed above differ, then you will 
have to adjust them accordingly to your system configuration.


--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list