<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
ndufresne: tfiga, I think it was this file -> Allegro_HEVC_Main10_MT51_BITDEPTHRND_00_1920x1080@60Hz_1.8.bin but I can't find back the file now
hverkuil: <u>syoung</u>: can you look at https://patchwork.linuxtv.org/patch/57611/ ? Â I think it is wrong sinc
<br> e it removes debug functionality, and I think it should just check against DVB_PLL_MAX. But I don't know if
<br> DVB_PLL_MAX is an overly restrictive number.
***: jmondi has quit IRC (Read error: Connection reset by peer)
<br> prabhakarlad has left
KitsuWhooa: Any idea if saa7134 is supposed to block applications for a few seconds during ioctls?
<br> For example there's one when switching between inputs, or trying to set the input standard
<br> I'm trying to figure out if it does this because I set something wrong for my specific card or it's supposed to be that way
hverkuil: <u>KitsuWhooa</u>: it might be, it probably depends on the tuner that your card uses. Some tuners need a fw update in certain circumstances, which takes time.
<br> Does dmesg tell you what tuner is used by your card?
KitsuWhooa: Out of the box the card isn't supported, I am making a patch to add support for it. I saw the tuner ic on the pcb but I can't remember the model. I do know it is supported by the TDA8290 driver though
<br> and this happens even when switching from composite to s-video, so I don't think it's necessarily the tuner
<br> one moment, will shut the computer down and take the card out to check the tuner
<br> Under the can there's a TDA8275
<br> and I have .tuner_type = TUNER_PHILIPS_TDA8290
hverkuil: That tuner doesn't need fw, so that's not it.
<br> I see some audio scanning thread in the code. Try to load the module with module option audio_debug=1 and see if you get some useful information in the kernel log.
KitsuWhooa: hmmm
<br> I have saa7134_alsa blacklisted so that I can easily unload it without killing pulseaudio
<br> I wonder if that is what cause it
<br> *causes it
hverkuil: It's a very long time ago that I last used a saa7134...
KitsuWhooa: understandable :p
<br> My alternative is a bt878 but it doesn't like my VCR and drops sync
hverkuil: It's worth a try to un-blacklist the saa7134_alsa, just to check that that isn't the culprit.
KitsuWhooa: Sure. I've been meaning to, to check that audio works too, as I'm going to submit the patch
hverkuil: I suspect something weird in drivers/media/pci/saa7134/saa7134-tvaudio.c, but that's just guesswork.
<br> You may have to dig deeper to see what is blocking an ioctl.
KitsuWhooa: I should probably use strace to see which exact ioctl blocks, yeah
<br> thank you
<br> one more question regarding dvb. How do I know which one I have to pick for my card? https://elixir.bootlin.com/linux/latest/source/drivers/media/pci/saa7134/saa7134.h#L375
<br> I couldn't find any info on a google search on what "empress" is, but I'm probably searching the wrong places
hverkuil: empress is a variant with a saa6752hs mpeg encoder chip: it can encode the analog video to an mpeg stream.
KitsuWhooa: I only see a TDA10046A, so I guess it's SAA7134_MPEG_DVB
hverkuil: yeah
KitsuWhooa: alright, thanks
***: benjiG has left
KitsuWhooa: latency did not go away, but I do notice that I'm not getting any audio through the card
<br> well, delay, not latency
hverkuil: which board is it? Or are you trying to add a new board to this driver?
KitsuWhooa: I have two boards I'm trying to add. They must be quite similar, but I'm trying to add one of them
<br> [ 1563.126902] saa7134: saa7133[0]: subsystem: 1458:9002, board: Gigabyte GT-PTV-TAF-RH [card=197,autodetected]
hverkuil: You usually need to experiment with the amux values. You never know how they are hooked up. And sometimes there's a gpiomask involved as well.
KitsuWhooa: gpio is only used for radio from what I can tell
<br> I used regspy from dscaler and the windows driver
<br> but yeah, I most likely need to figure out the amux values
<br> I guess I'll do that first and then see if the delay persists
hverkuil: ok
KitsuWhooa: thank you again for your time
<br> much appreciated
<br> looks like I found the right amux value, but audio is mono and choppy
hverkuil: I see different values for audio_clock in the various card definitions. Might be something to play with as well.
<br> seems to be either 0x00200000 or 0x00187de7.
KitsuWhooa: hm, that might be it
<br> https://linuxtv.org/downloads/v4l-dvb-apis/v4l-drivers/saa7134.html#card-variations
<br> nope, crystal is 32.1MHz
<br> .audio_clock = 0x00187de7,
<br> it seems to have fixed itself, so I am going to guess it's pulseaudio acting up
<br> Maybe that's also why it's mono
<br> Hm, only option I have is "Analog Mono Input"
hverkuil: what's your input? TV or S-Video/Composite?
KitsuWhooa: Composite
<br> I unloaded the pulseaudio alsa module for the card and used qv4l2 for audio playback and this has stereo now
<br> This is odd...
<br> The delay seems to have gotten better, but it still takes a few hundred ms when calling VIDIOC_G_INPUT for example
hverkuil: v4l2-ctl --get-input takes that long?
KitsuWhooa: I meant to paste VIDIOC_S_INPUT, sorry, however that also takes a bit
<br> $ time v4l2-ctl --get-input
<br> Video input : 1 (Composite1: no signal, no hsync lock)
<br> real 0m0,718s
hverkuil: Check the video_mux function, I suspect that one.
<br> It's called by s_input, but also when you open a video device.
<br> Does s_input take about twice as much time as g_input?
KitsuWhooa: looks like it
<br> $ time v4l2-ctl --set-input 2
<br> Video input set to 2 (S-Video: Camera, no signal, no hsync lock)
<br> real 0m1,377s
hverkuil: Yeah, so something in the video_mux function is slow. It calls two other functions, you'd have to dig a bit deeper which one it is.
KitsuWhooa: Alright, I'll have a look. That aside, so far composite and analog tv work fine with audio
hverkuil: nice
KitsuWhooa: I assume S-Video will too since it uses the same amux and I got the vmux values from regspy
<br> but will definitely test
hverkuil: ttyl
KitsuWhooa: Alright, thanks again
<br> looks like it might be unavoidable as if there's an input signal the delay is much smaller