said E. Liddell via tde-users: | On Thu, 23 May 2024 17:57:51 +0000 | | dep via tde-users <users@xxxxxxxxxxxxxxxxxx> wrote: | > As I said, no sound. The occasional crackle or alarming pop. Video is | > fine. EPG is fine. Started it in a terminal and after the expected | > bitching about not liking my desktop, this: | > | > [code] | > mpeg2_v4l2m2m @ 0x7fff5804e100] Could not find a valid device | > [mpeg2_v4l2m2m @ 0x7fff5804e100] can't configure decoder | > [00007fff58013710] avcodec decoder error: cannot start codec | > (mpeg2_v4l2m2m) [00005556238c9770] main audio output error: too low | > audio sample frequency (0) [00007fff58053150] main decoder error: | > failed to create audio output [mpeg2_v4l2m2m @ 0x7fff5804e100] Could | > not find a valid device [mpeg2_v4l2m2m @ 0x7fff5804e100] can't | > configure decoder | > [00007fff58013710] avcodec decoder error: cannot start codec | > (mpeg2_v4l2m2m) [00007fff40006870] gles2 gl: Initialized libplacebo | > v4.208.0 (API v208) [mpeg2video @ 0x7fff5804e100] get_buffer() failed | > [mpeg2video @ 0x7fff5804e100] get_buffer() failed (-12 (nil)) | > [/code] | | The thing that stands out to me here is the "v4l" bit showing up in one | of the codec names. That last character is an L, not a 1, so it's | presumably referring to Video4Linux, which is a set of kernel drivers | for video hardware. The sequence seems to suggest that v4l isn't quite | working right and can't get the audio feed. | | kaffeine doesn't link v4l itself, but picks it up through xine-lib. | xine-lib may be linking it directly or picking it up through ffmpeg, | depending on how your distro has it set up. The presence of "avcodec" | in the trace suggests ffmpeg's involvement. | | So I'd start at the kernel level, verify that the correct drivers are | available and being attached to the correct devices, then move upward | through ffmpeg and xine-lib. (If VLC, which uses libmpeg2 for mpeg2 | decoding, happens to work, that would practically be a smoking gun | pointing at ffmpeg or xine.) Thank you. A couple of things that may or may not be pertinent. First, both VLC and Kaffeine work just fine with everything else. Second, support for the TV device, a Hauppauge 1595, has supposedly been in the kernel for years now. This makes me hesitant to d/l Hauppague's stuff, which lists itself as working in Ubuntu 14.04 -- 10 years old. I've gotten and run w_scan_cpp, many times, making channels.conf (and many other formats, all the possibilities) in hope of narrowing the problem, in that Kaffeine and VLC are essentially the same thing. Apparently mplayer gets its signal some other way, and if I can figure out how to work the thing I hope to learn if the issue is farther upstream. (A terminal television program seems a bit like a blind taxi driver.) The mplayer GUI is possibly the most counter-intuitive thing since emacs (or WordPerfect). There's a shortage of video programs that don't hang off VLC. Clearly. something is working, in that the Hauppauge gadget is delivering the image just fine -- it's the sound that is screwy. Added to this is the change from Pulseaudio to Pipewire, and the plethora of adapters designed to translate from one to the other. In practical terms this means that I've read and tried things that have been obviated in the last couple of years. (The web is not big on putting dates on things.) I can't help but think that there's a switch someplace that if turned from off to on or vice versa, is changed to or from alsa, something, will make it work. (Example: there is a dandy Raspberry Pi utility that duplicates the SD card in the machine. It is useful for all sorts of things, especially for making a copy of the working system on your SSD, to keep close at hand for when you break it. But when you boot the new SD, you quickly discover you're back in the system on the SSD. Reason is, and it was not easy to find, is that the duplicating program has a little checkbox, "New Partition UUIDs," that by default is unchecked. If you boot from an SD onto a device that has an SSD with the same UUID, partway through the boot it hands everything off to the SSD. There might be a reason to leave that box unchecked by default, but you cannot imagine how much trouble it has caused. What's more, there's no instant way of determining which is the booted device. I learned the trick -- check the box -- but whenever I'm fixing to boot from flopp . . . oops, SD, I make a point of changing the color of the desktop forst, to pink or something, so I can tell that the SD is what's running.) Linux audio is and always has been a lot like car dashboard wiring. Maybe you can get what's broken to work, but there's a good chance you just have to live with it. I have no idea in the world how to do diagnostics on all this. -- dep Pictures: http://www.ipernity.com/doc/depscribe/album Column: https://ofb.biz/author/dep/ ____________________________________________________ tde-users mailing list -- users@xxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxx Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@xxxxxxxxxxxxxxxxxx
