ATI "HDTV Wonder" audio

ATI "HDTV Wonder" audio

[Bill Davidsen]

I'm trying to use an HDTV Wonder, using the cx88 chipset, and I am 
getting no sound. Originally I was getting the native sound disabled by 
the card, just putting it in a system. However, by moving the driver 
usiung "index=" in modprobe.conf, I can keep sound for everything except 
the card. It will grab an image just fine, but there's no audio.

Is there a known solution? Google didn't find one in English, and I 
assume that it's as simple as an option in the module load, if I know 
what module to change. I tried the cx88_alsa, and alsamixer sees the 
card, but doesn't capture the sound.

-- 
Bill Davidsen <davidsen@tmr.com>
  "Woe unto the statesman who makes war without a reason that will still
  be valid when the war is over..." Otto von Bismark 


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

ATI "HDTV Wonder" audio

[CityK]

> I'm trying to use an HDTV Wonder, using the cx88 chipset, and I am 
> getting no sound. Originally I was getting the native sound disabled 
> by the card, just putting it in a system. However, by moving the 
> driver usiung "index=" in modprobe.conf, I can keep sound for 
> everything except the card. It will grab an image just fine, but 
> there's no audio. Is there a known solution? Google didn't find one in 
> English, and I assume that it's as simple as an option in the module 
> load, if I know what module to change. I tried the cx88_alsa, and 
> alsamixer sees the card, but doesn't capture the sound.


cx88 supports tv-audio only; it does not feature ADC for external audio
sources.  This point is alluded to in the wiki:
http://www.linuxtv.org/wiki/index.php/ATI/AMD_HDTV_Wonder

Further explanation is found within this post here:
http://marc.info/?l=linux-dvb&m=119955615903163&w=2

I doubt very much that anything will ever be heard from the person
originally looking at the ak5355, so those seeking a driver will need to
write it themselves ... the chip's data sheet is available and appears 
to be straight forward.

Good luck.

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

Re: ATI "HDTV Wonder" audio

[hermann pitton]

Am Samstag, den 15.03.2008, 17:44 -0400 schrieb CityK:
> > I'm trying to use an HDTV Wonder, using the cx88 chipset, and I am 
> > getting no sound. Originally I was getting the native sound disabled 
> > by the card, just putting it in a system. However, by moving the 
> > driver usiung "index=" in modprobe.conf, I can keep sound for 
> > everything except the card. It will grab an image just fine, but 
> > there's no audio. Is there a known solution? Google didn't find one in 
> > English, and I assume that it's as simple as an option in the module 
> > load, if I know what module to change. I tried the cx88_alsa, and 
> > alsamixer sees the card, but doesn't capture the sound.
> 
> 
> cx88 supports tv-audio only; it does not feature ADC for external audio
> sources.  This point is alluded to in the wiki:
> http://www.linuxtv.org/wiki/index.php/ATI/AMD_HDTV_Wonder
> 
> Further explanation is found within this post here:
> http://marc.info/?l=linux-dvb&m=119955615903163&w=2
> 
> I doubt very much that anything will ever be heard from the person
> originally looking at the ak5355, so those seeking a driver will need to
> write it themselves ... the chip's data sheet is available and appears 
> to be straight forward.
> 
> Good luck.
> 

Hi CityK and all interested,

for sure blame me not being up to date on this and I am not even sure,
what it is all about. 

For example, since the using of cx88-alsa seems to be intended, analog
NTSC with picture, but no sound from tuner is reported (?) 

Or like you pointed now, likely analog video from an external input and
then missing the specific ADC support for external analog audio input?

Without looking any deeper back, but slightly wondering, why has the
TUV1236D the TDA9887_PRESENT on the saa7134 cards, but not on this one?

Is it at all about analog NTSC-M video working from the tuner?
But no sound, hrmm ;)

Cheers,
Hermann




 

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

Re: ATI "HDTV Wonder" audio

[CityK]

Hi Hermann

hermann pitton wrote:
> for sure blame me not being up to date on this and I am not even sure,
> what it is all about. 
>
> For example, since the using of cx88-alsa seems to be intended, analog
> NTSC with picture, but no sound from tuner is reported (?) 
>
> Or like you pointed now, likely analog video from an external input and
> then missing the specific ADC support for external analog audio input?
>
> ...
>
> Is it at all about analog NTSC-M video working from the tuner?
> But no sound, hrmm ;)
>   
Oops ... umm, its not that I  failed to take broadcast audio into 
consideration (as I wasn't sure if Bill was talking about broadcast 
audio too), its just that I was hell bent on talking about the external 
audio problem :P 

So now, for a more complete picture:
IIRC, 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, while the cx88 will perform ADC for analog 
broadcast audio, you would indeed need to use cx88-alsa, as quite 
correctly alluded to by Hermann.  In the more limited case (which I had 
wrongly only took into consideration) one will be unable to receive 
external audio for the reasons I specified -- i.e. cx88 doesn't do ADC 
for external audio; need a driver for the AK5355 for that, and then 
correctly code for the GPIO pins for the cx88 as used on the HDTV Wonder.

> Without looking any deeper back, but slightly wondering, why has the
> TUV1236D the TDA9887_PRESENT on the saa7134 cards, but not on this one?

Just a mistake on my part lead to the confusion.  TDA9887 present in all 
cases of TUV1236D.

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

Re: ATI "HDTV Wonder" audio

[hermann pitton]

Am Samstag, den 15.03.2008, 20:00 -0400 schrieb CityK:
> Hi Hermann
> 
> hermann pitton wrote:
> > for sure blame me not being up to date on this and I am not even sure,
> > what it is all about. 
> >
> > For example, since the using of cx88-alsa seems to be intended, analog
> > NTSC with picture, but no sound from tuner is reported (?) 
> >
> > Or like you pointed now, likely analog video from an external input and
> > then missing the specific ADC support for external analog audio input?
> >
> > ...
> >
> > Is it at all about analog NTSC-M video working from the tuner?
> > But no sound, hrmm ;)
> >   
> Oops ... umm, its not that I  failed to take broadcast audio into 
> consideration (as I wasn't sure if Bill was talking about broadcast 
> audio too), its just that I was hell bent on talking about the external 
> audio problem :P 
> 
> So now, for a more complete picture:
> IIRC, 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, while the cx88 will perform ADC for analog 
> broadcast audio, you would indeed need to use cx88-alsa, as quite 
> correctly alluded to by Hermann.  In the more limited case (which I had 
> wrongly only took into consideration) one will be unable to receive 
> external audio for the reasons I specified -- i.e. cx88 doesn't do ADC 
> for external audio; need a driver for the AK5355 for that, and then 
> correctly code for the GPIO pins for the cx88 as used on the HDTV Wonder.
> 
> > Without looking any deeper back, but slightly wondering, why has the
> > TUV1236D the TDA9887_PRESENT on the saa7134 cards, but not on this one?
> 
> Just a mistake on my part lead to the confusion.  TDA9887 present in all 
> cases of TUV1236D.

Had the _pleasure_ to help to get audio on the previous Wonder Pro, so
first thought it was about this one with the broken tda9887 config
options from the cards recently, but is not and on the hdtv wonder the
entry is missing.

	[CX88_BOARD_ATI_HDTVWONDER] = {
		.name           = "ATI HDTV Wonder",
		.tuner_type     = TUNER_PHILIPS_TUV1236D,
		.radio_type     = UNSET,
		.tuner_addr	= ADDR_UNSET,
		.radio_addr	= ADDR_UNSET,
		.input          = {{
			.type   = CX88_VMUX_TELEVISION,
			.vmux   = 0,
			.gpio0  = 0x00000ff7,
			.gpio1  = 0x000000ff,
			.gpio2  = 0x00000001,
			.gpio3  = 0x00000000,
		},{
			.type   = CX88_VMUX_COMPOSITE1,
			.vmux   = 1,
			.gpio0  = 0x00000ffe,
			.gpio1  = 0x000000ff,
			.gpio2  = 0x00000001,
			.gpio3  = 0x00000000,
		},{
			.type   = CX88_VMUX_SVIDEO,
			.vmux   = 2,
			.gpio0  = 0x00000ffe,
			.gpio1  = 0x000000ff,
			.gpio2  = 0x00000001,
			.gpio3  = 0x00000000,
		}},
		.mpeg           = CX88_MPEG_DVB,
	},

However, Mike could have it in tuner-types. But is not there.

/* ------------ TUNER_PHILIPS_TUV1236D - Philips ATSC ------------ */

static struct tuner_range tuner_tuv1236d_ntsc_ranges[] = {
	{ 16 * 157.25 /*MHz*/, 0xce, 0x01, },
	{ 16 * 454.00 /*MHz*/, 0xce, 0x02, },
	{ 16 * 999.99        , 0xce, 0x04, },
};

static struct tuner_range tuner_tuv1236d_atsc_ranges[] = {
	{ 16 * 157.25 /*MHz*/, 0xc6, 0x41, },
	{ 16 * 454.00 /*MHz*/, 0xc6, 0x42, },
	{ 16 * 999.99        , 0xc6, 0x44, },
};

static struct tuner_params tuner_tuv1236d_params[] = {
	{
		.type   = TUNER_PARAM_TYPE_NTSC,
		.ranges = tuner_tuv1236d_ntsc_ranges,
		.count  = ARRAY_SIZE(tuner_tuv1236d_ntsc_ranges),
	},
	{
		.type   = TUNER_PARAM_TYPE_DIGITAL,
		.ranges = tuner_tuv1236d_atsc_ranges,
		.count  = ARRAY_SIZE(tuner_tuv1236d_atsc_ranges),
		.iffreq = 16 * 44.00,
	},
};

As said, not in details yet, but seems there is some pain.

The tda9887 can be configured for NTSC, and only for that, to be
hardwired without needing any i2c programming, but then I would expect
not only "picture", but also functional audio.

We need better reports with debug options enabled I guess.

Cheers,
Hermann






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

Re: ATI "HDTV Wonder" audio

[Bill Davidsen]

CityK wrote:
> Hi Hermann
> 
> hermann pitton wrote:
>> for sure blame me not being up to date on this and I am not even sure,
>> what it is all about.
>> For example, since the using of cx88-alsa seems to be intended, analog
>> NTSC with picture, but no sound from tuner is reported (?)
>> Or like you pointed now, likely analog video from an external input and
>> then missing the specific ADC support for external analog audio input?
>>
>> ...
>>
>> Is it at all about analog NTSC-M video working from the tuner?
>> But no sound, hrmm ;)
>>   
> Oops ... umm, its not that I  failed to take broadcast audio into 
> consideration (as I wasn't sure if Bill was talking about broadcast 
> audio too), its just that I was hell bent on talking about the external 
> audio problem :P

I'm not sure what you mean by external audio, 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. 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.

> So now, for a more complete picture:
> IIRC, 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, while the cx88 will perform ADC for analog 
> broadcast audio, you would indeed need to use cx88-alsa, as quite 
> correctly alluded to by Hermann.  In the more limited case (which I had 
> wrongly only took into consideration) one will be unable to receive 
> external audio for the reasons I specified -- i.e. cx88 doesn't do ADC 
> for external audio; need a driver for the AK5355 for that, and then 
> correctly code for the GPIO pins for the cx88 as used on the HDTV Wonder.
> 
As noted in my original post, I'm using cx88_alsa, 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.


-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

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

Re: ATI "HDTV Wonder" audio

[CityK]

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

Re: ATI "HDTV Wonder" audio

[Bill Davidsen]

CityK wrote:
> 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.
> 
As you note later, I'm not trying to get sound in, but out. But it's 
interesting that alsamixer shows both an input (capture) and output 
device for this card. And that makes sense, the dongle which connects to 
the "looks like S_Video but isn't" socket has connectors for S_Video, 
composite audio, and L-R channel audio, so I suspect that if I could 
ever get sound *out* of the card I could get it *in*. Since I really 
want this to grab output from a HD-DVR in HD, I'd like to think the 
S_Video is the answer.

> - 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).
> 
I used to design and build ham radio receivers, I think I grasp the 
concept. ;-)

	[__snip__]

> 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
> 
At this point I'll state (or restate) that there are traces for a 
connector as is used by CD feeds, and as are found on several of my 
other ATI boards (all low def). I suppose I could populate the board and 
run a cable, although that would involve multiple A<->D conversions.

> 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.

Given the lack of analog output connections, I hope that's the case. As 
noted it works with Windows.

> 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.
> 
I've been fighting with this for a while, and AFAIK there is everything 
except the actual socket on the card. There certainly are traces for the 
installation of the connector, I can't check the need for components 
while it's up and doing something, but I will check later tonight.
> 
> 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 really appreciate the time you took to understand this, I hope the 
additional information I'm providing is useful...

>> 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.
> 
I don't see any such thing. I doubt attachments are allowed, but I'll 
just put "lspci -n" at the end of this post.

> 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.
> 
Some success, this actually does get sound and picture. However, the 
capture from the card is small, 384x288, regardless of settings. Clearly 
not the HD I'm trying to get.

Those parameters don't really work with mencoder, so I can't record 
anything under any conditions... it "records" and I get a black screen 
silent movie. I couldn't get ffmpeg to record either, or even try.

After about two years of "try, then wait for the next better drivers or 
kernel fix," I'm about ready to admit that Linux just can't do the job, 
and the more I search for answers the more I find zero people who say 
they have gotten *any* currently available consumer priced hardware to 
do HD capture, and the more people I find on lists and websites and IRC 
asking how to do this and getting no answer. After two years the driver 
still doesn't work usefully, and by now I can't buy more cards new, and 
I should start over by buying a new card if there was a working "over" 
to start.

-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

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

Re: ATI "HDTV Wonder" audio

[Bill Davidsen]

Bill Davidsen wrote:
>
> I don't see any such thing. I doubt attachments are allowed, but I'll 
> just put "lspci -n" at the end of this post.
Well, that post just vanished, let me try again.

lspci -n

00:00.0 0600: 8086:2570 (rev 02)
00:01.0 0604: 8086:2571 (rev 02)
00:1d.0 0c03: 8086:24d2 (rev 02)
00:1d.1 0c03: 8086:24d4 (rev 02)
00:1d.2 0c03: 8086:24d7 (rev 02)
00:1d.3 0c03: 8086:24de (rev 02)
00:1d.7 0c03: 8086:24dd (rev 02)
00:1e.0 0604: 8086:244e (rev c2)
00:1f.0 0601: 8086:24d0 (rev 02)
00:1f.1 0101: 8086:24db (rev 02)
00:1f.3 0c05: 8086:24d3 (rev 02)
00:1f.5 0401: 8086:24d5 (rev 02)
01:00.0 0300: 1002:5159
02:03.0 0c00: 1106:3044 (rev 46)
02:04.0 0104: 1106:3164 (rev 06)
02:05.0 0200: 10b7:1700 (rev 12)
02:09.0 0180: 105a:4d69 (rev 02)
02:0c.0 0400: 14f1:8800 (rev 05)
02:0c.1 0480: 14f1:8801 (rev 05)
02:0c.2 0480: 14f1:8802 (rev 05)


lspci



00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM 
Controller/Host-Hub Interface (rev 02)
00:01.0 PCI bridge: Intel Corporation 82865G/PE/P PCI to AGP Controller 
(rev 02)
00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB 
UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB 
UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB 
UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB 
UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 
EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2)
00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC 
Interface Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE 
Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus 
Controller (rev 02)
00:1f.5 Multimedia audio controller: Intel Corporation 82801EB/ER 
(ICH5/ICH5R) AC'97 Audio Controller (rev 02)
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY 
[Radeon 7000/VE]
02:03.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host 
Controller (rev 46)
02:04.0 RAID bus controller: VIA Technologies, Inc. VT6410 ATA133 RAID 
controller (rev 06)
02:05.0 Ethernet controller: 3Com Corporation 3c940 10/100/1000Base-T 
[Marvell] (rev 12)
02:09.0 Mass storage controller: Promise Technology, Inc. 20269 (rev 02)
02:0c.0 Multimedia video controller: Conexant CX23880/1/2/3 PCI Video 
and Audio Decoder (rev 05)
02:0c.1 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and 
Audio Decoder [Audio Port] (rev 05)
02:0c.2 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and 
Audio Decoder [MPEG Port] (rev 05)

lspci -vv (video only)

02:0c.0 Multimedia video controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder (rev 05)
        Subsystem: ATI Technologies Inc HDTV Wonder
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 64 (5000ns min, 13750ns max), Cache Line Size: 16 bytes
        Interrupt: pin A routed to IRQ 23
        Region 0: Memory at f4000000 (32-bit, non-prefetchable) [size=16M]
        Capabilities: [44] Vital Product Data <?>
        Capabilities: [4c] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: cx8800
        Kernel modules: cx8800

02:0c.1 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [Audio Port] (rev 05)
        Subsystem: ATI Technologies Inc Unknown device a101
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 64 (1000ns min, 63750ns max), Cache Line Size: 16 bytes
        Interrupt: pin A routed to IRQ 23
        Region 0: Memory at f5000000 (32-bit, non-prefetchable) [size=16M]
        Capabilities: [4c] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: cx88_audio
        Kernel modules: cx88-alsa

02:0c.2 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] (rev 05)
        Subsystem: ATI Technologies Inc Unknown device a101
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 64 (1500ns min, 22000ns max), Cache Line Size: 16 bytes
        Interrupt: pin A routed to IRQ 23
        Region 0: Memory at f6000000 (32-bit, non-prefetchable) [size=16M]
        Capabilities: [4c] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: cx88-mpeg driver manager
        Kernel modules: cx8802


Hope this gets through!

-- 
Bill Davidsen <davidsen@tmr.com>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

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

Re: ATI "HDTV Wonder" audio

[CityK]

Bill Davidsen wrote:
> As you note later, I'm not trying to get sound in, but out. 

In laymans terms, you ARE trying to get sound IN [to the system] ... if 
you zoom in to look at or dissect the actual process from a functional 
perspective, then yes, technically what you are trying to accomplish is 
getting the sound out of the cx88 chip and off the card ..... BUT for 
all intense purposes, this goal is so that you can get sound IN to the 
host computer system. 

This contrasts to the case of when one talks about getting sound out, as 
it almost always refers to the aspect of routing the sound outside the 
host computer system, to say a discrete stereo receiver  for 
handling/processing or whatever.

> the dongle which connects to the "looks like S_Video but isn't" socket 
> has connectors for S_Video, composite audio, and L-R channel audio

Its a mini-DIN connector ... if I recall, the ATI "Barney Purple" dongle 
is an 8pin version

DIN connectors are standardized .... though you will often see articles 
on the web in which the reviewer, upon encountering the "looks like 
S_Video but isn't", mis-reports it as being a proprietary connector. 

For some further background see: 
http://en.wikipedia.org/wiki/Mini-DIN_connector

> Since I really want this to grab output from a HD-DVR in HD, I'd like 
> to think the S_Video is the answer.

No.  You can not capture at HD resolutions with S-Video. 

The only analog interfaces that would allow you to capture at HD 
resolutions would be a HD component or VGA solution. 

There are many A/V decoder chips that are capable of capturing component 
signals.  Some of these would even be able to handle HD component.  
There are ZERO consumer  capture cards  that have component inputs. 

There are a couple of inexpensive prosumer cards with HD component input 
(eg. BM's Intensity Pro).  None of them have Linux drivers. 

There are a couple of EXPENSIVE prosumer/pro cards that feature HD 
component and/or VGA input.  None of them have open Linux drivers.  Most 
of these do, however, have proprietary Linux drivers.

> At this point I'll state (or restate) that there are traces for a 
> connector as is used by CD feeds, and as are found on several of my 
> other ATI boards 

Yes, the traditional internal loopback cable for getting an analog 
signal off the card.

Some boards offer/"are_wired" to send an analog signal off the card via 
an "external to the innards of the host system" approach whereby you'd 
run a mini-stereo connector from the back riser of the tv card and plug 
it into the mini-stereo input jack on the riser of your sound card

Some boards offer both ways -- an internal header for a loopback cable 
and an audio out on the riser.

> I suppose I could populate the board and run a cable .... AFAIK there 
> is everything except the actual socket on the card. There certainly 
> are traces for the installation of the connector, 

I rather imagine that it would indeed work ... can't see any reason why 
it would be inert...its actually rather bizarre that ATI did not include 
the header for a loopback cable ... as, as I alluded to earlier, this is 
pretty much defacto way.

> although that would involve multiple A<->D conversions. 

yes, having done the ADC once, it would be nice to keep things in the 
digital domain .... and (strictly from an operational analysis) 
following the analog route is rather an inefficient  pathway ... 
nonetheless, the analog way works well, is the defacto method, and can 
be less troublesome (particulary under Linux)

> (all low def).

I'm commenting on this point because, having browsed through your reply 
it is clear that you have formed some common misconceptions  ... one of 
which would appear to include that you are under the impression that a 
run of the mill hybrid digital/analog receiver card should be able to 
perform analog captures at HD resolutions ... this is NOT the case ... 
much of the confusion surrounds the misuse of the word "capture", 
especially when it is used in regards to such cards like the HDTV Wonder 
in a fashion such as calling them "HD capture card" 

>> 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.
> Given the lack of analog output connections, I hope that's the case. 
> As noted it works with Windows.

You missed some points here:

(1) the context of my comment here was in regards to :  "in the case of 
cards using TUV1236D & saa7135"  .... this does not include your card

For your card, the HDTV Wonder  (and others like it that are TUV1236D & 
cx88 based card ... though, offhand, I don't believe there are any 
others using this chip combination), and as noted in the sidebar 
discussion of my last message, the route for the TV-in audio for cards 
is fixed/hardwired -- recall: cx88 lacks baseband audio handling 
capabilities

(2) the lack of analog output connections on the HDTV Wonder is 
irrelevant ... in neither way is one aspect reflective of the other  
i.e. that the TV-in audio pathway to the cx88 is hardwired has no 
bearing on whether the card will feature analog output connections  
..and vice versa, the lack of analog output connections is not 
indicative of how the TV-in audio pathway to the cx88 is wired

The only thing that the lack of analog output connections on the HDTV 
Wonder points towards is that ATI made a rather bizarre decision .... 
Did they not populate the trace's termination point on the surface of 
the card with a plastic header and a couple of pins because it saved 
them $0.0002 in production costs per card?  did they not do it cause 
they thought it would look uncool or ruin the card's aesthetics ?  did 
someone just simply overlook this minor detail of including a header 
before they sent the final plans off to their Taiwanese manufacturing 
partners?  .... your guess is as good as mine.

3) Windows is doing audio dma ... its using the digital audio out 
pathway  ... but your note that it works in Windows isn't applicable to 
the context of the  sidebar discussion here ... though it is, of course, 
an applicable comment to the other discussion --- just not the side bar  
/ diversionary topic ;)


> I really appreciate the time you took

Thanks -- it truly is nice to read that.

>> 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.
> I don't see any such thing.

Sorry, my mistake ... the pci id for Conexant is 14f1, and their cx88 
chips' ID, of course, are given by the 88xx   .... When Ricardo first 
posted a note about cx88-alsa a couple of years ago, he had incorrectly 
used "1741" in his examples, and I just blindly related the same 
yesterday from my notes I had jotted down from Ricardo's message .... 
interestingly, I had never caught that mistake before ... though I have 
related the same to others in the past too --- hopefully I didn't 
confuse them too much :P

> I doubt attachments are allowed, but I'll just put "lspci -n" at the 
> end of this post.

Yep, attachments won't work.... you'd have to copy the output inline, or 
use a service like pastebin or whatever and then provide a link

In any regard, from you next post, I do notice that 14f1:8801 is indeed 
present from your lspci -n output

> success, this actually does get sound and picture. 

And that proof conclusively solves the question as to why it wasn't 
working!  Good to hear that you've got that sorted out now.  In 
hindsight, I probably should have picked up on this quicker.  Oh well, 
hopefully those following this thread are richer for the experience.

> Some success ...However, the capture from the card is small, 384x288, 
> regardless of settings. Clearly not the HD I'm trying to get.

As mentioned above, you're not going to get HD through a capture of an 
analog signal.

As a note, the whole point of this test was just to make sure that audio 
dma was working properly -- and evidently it is.  For your other concern 
here, you will have to adjust capture parameters accordingly if you want 
a larger window ... but do bear in mind that you will be limited to a 
capture resolution of 720x480 with an analog source with such a card.

> Those parameters don't really work with mencoder, so I can't record 
> anything under any conditions... it "records" and I get a black screen 
> silent movie. I couldn't get ffmpeg to record either, or even try.

I imagine that you just haven't set the mencoder or ffmpeg cmdline 
arguments quite right.


> After about two years of "try, then wait for the next better drivers 
> or kernel fix," I'm about ready to admit that Linux just can't do the 
> job, and the more I search for answers the more I find zero people who 
> say they have gotten *any* currently available consumer priced 
> hardware to do HD capture, and the more people I find on lists and 
> websites and IRC asking how to do this and getting no answer. After 
> two years the driver still doesn't work usefully, and by now I can't 
> buy more cards new, and I should start over by buying a new card if 
> there was a working "over" to start.

Your disappointment is based upon faulty expectations.

Here's the bottom line -- Overall, you've got a few things confused 
about these devices and how they work. ... its really easy to arrive 
such misconceptions too, especially given that the new user is typically 
going to be exposed to this stuff from the likes of internet forums etc, 
which unfortunately tend not to be the most precise of resources, as 
they, instead, tend to be filled with posts that gloss over details, 
fail to recognize nuances, and make liberal use of misnomers....its 
99.9% non-intentional, but nonetheless, it can lead the unaware astray

In any regard, how you arrived at or formulated these misconceptions, or 
from where or when they came is unimportant --- Just throw them out, and 
start afresh.

Also take comfort in the fact that the situation under Linux is little 
different from that of a Windows perspective.   If you are interested, 
you can read through this recent thread about "HD capture solutions" 
under Linux.  You should also read that Doom9 thread to which I linked, 
as it touches upon the very few able solutions that can be used under 
Windows -- which are not easily available, not fool proof, and are 
subject to a wide range of technical considerations and constraints.

Got to run. Cheers.

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