Recurring audio issues with Ubuntu 16.04 - audio

I'm using Ubuntu 16.04 on a Dell Inspiron (uname -a returns Linux 4.8.0-49-generic #52~16.04.1-Ubuntu SMP Thu Apr 20 10:55:59 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux). The audio device (as reported by lspci) is Intel Intel Corporation Device 9d71 (rev 21).
I'm having recurring loss of the hardware audio device at random times when I plug in a headphone into the audio jack. Subsequently, audio settings in the System Settings show no audio output or input devices. aplay -l returns PCH[HDA Intel PCH] repeated 3 times.
This is a new laptop, and there were no problems of any kind after the Xenial 16.04 was installed two weeks back. Even now, it is very robust except for the audio problem.
When this happened last week, I managed to get the audio back by installing DKMS, but the audio has failed again today and this is not working.
TIA for any pointers on why plugging in a headphone/ear-piece should result in such a catastrophic condition, and also on how to fix this permanently. Searching for audio problems on Ubuntu 16.04 results in a deluge of pages, and it is very hard to figure out which works and which would screw up my system further...
s1b

Related

How to play audio in docker container on raspberry pi?

I would like to play audio on my raspberry pi, the audio player (console application) should in a docker container. I have seen multiple articles on the web, they commonly suggest to add the --device /dev/snd to the docker run. I just can't seem to get the audio through. Audio should be played on the device that's attached via HDMI cable. I tried sox player, I took ubuntu 18.04 as base image and also this sample solution. I'm flexible with with what the media player application is as this is a hobby project (would be nice that I can "pipe" an mp3 file to the program via bash while it is being streamed from somewhere). On the host I recently installed "Raspberry Pi OS with desktop and recommended software". (Release date is October 30th 2021, Kernel version: 5.10, whatever came with it). Pi 2 model B 1.1 (2014).
UPDATE: Audio does play on 3.5mm jack
It seems that by using the --device /dev/snd option, audio does play on the 3.5mm jack. I don't know though how to make this work on the HDMI.

camera capture looks different on windows and linux

hey im trying to use a raspberry pi with opencv to prosses some images but while i am capturing the images from the webcam using the same values using windows on my pc and Ubuntu mate on the pi they look very different
linux capture
windows capture
does anyone know why there any difference
It looks like your usb webcam probably has a compatibility problem with the pi (or its drivers in Ubuntu mate).
Try googling the camera model and linux compatibility to see if there are any known tricks to do.
Googling "raspberry pi usb camera compatibility" gives you various lists of known compatible cameras.
In terms of performance (e.g. frame rate) a usb webcam is always worse than the raspberry pi camera attached to the camera serial interface.
To get that working in opencv, you can use this library:
RaspiCam: C++ API for using Raspberry camera with/without OpenCv
www.uco.es/investiga/grupos/ava/node/40

Joystick Constant Disconnecting Problems Linux

I'm trying to get a joystick to work but my device is having problems seeing it. I will plug in the joystick, it will show up under /dev/input/ but it will disappear after a few seconds, then reappear, and repeat. Also, I installed the joystick package but js0 never shows up.
When it does show up this is the info I get:
Bus 001 Device 079: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 064: ID 068e:0105 CH Products, Inc.
(This 064 number listed in the last device on this list increments over time since it keeps disconnecting over and over)
root#pc-zed:/dev/input# ls
by-id by-path event0 event1 mice mouse0
root#pc-zed:/dev/input/by-path# ls
platform-xusbps-ehci.0-usb-0:1.2:1.0-event-joystick
platform-xusbps-ehci.0-usb-0:1.2:1.1-event-mouse
platform-xusbps-ehci.0-usb-0:1.2:1.1-mouse
root#pc-zed:/dev/input/by-id# ls
usb-CH_Products_APEM_HF_Joystick-event-joystick
usb-CH_Products_APEM_HF_Joystick-event-mouse
usb-CH_Products_APEM_HF_Joystick-if01-event-mouse
usb-CH_Products_APEM_HF_Joystick-if01-mouse
usb-CH_Products_APEM_HF_Joystick-mouse
The piece of hardware I'm running this on is a ZedBoard with a 3.12.0-xillinux-1.3 kernel
Distributor ID: Ubuntu
Description: Ubuntu 12.04 LTS
Release: 12.04
Codename: precise
I've tried this with a USB hub to ensure this isn't a power issue.
If anyone has any ideas please let me know! Thank you.

Understanding RSSI inacurracy on RaspberryPi

I'm experimenting with iBeacon tracking on a RaspberryPi and have a problem with the accuracy of the retrieved RSSI. I use the following hardware:
- RaspberryPi (newest version)
- IOGear Bluetooth 4.0 USB Micro Adapter
- BEACONinside Beacon (Model: B0001-A)
I tested iBeacon advertisment scanning using the official BEACONinside Android app and the retrieved RSSI is intuitively very accurate. Then I tested advertisment scanning using aforementioned hardware on a RaspberryPi and the retrieved RSSI is very inaccurate. Does anybody have an idea what the reason for this inacurracy could be? Possible origins for the problem are in my optinion the Bluetooth adpater, which differs from the one in my Android phone. Another reason could be the library for Bluetooth scanning (on the RaspberryPi, I'm using bluez). What do you think?
RSSI is generally effected by surrounding environments so it should be
averaged for couple of seconds to get accurate value

Cannot program Atmega1284p with arduino on linux, works on mac

This issue is driving me nuts. I am working on a project with some other guys who built the electronics. We have custom boards with an atmega 1284p. For USB cummunication with the 1284p we use a FTDI FT230X USB Bridge. This doesn't have DTR; RTS is used to reset the board using a capacitor (pretty much like with off the shelf arduinos).
The arduino bootloader is used, and we use mighty-1284p to upload. The board selected is "Original Mighty 1284p 8MHz". After installing the right FTDI drivers from http://www.ftdichip.com/Drivers/VCP.htm I can upload to the board from a mac. Linux has these drivers built into the kernel. However, I cannot upload to the board. AVR gives the following error:
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
avrdude: Send: 0 [30] [20]
dmesg gives the following:
...
[ 51.299964] usbcore: registered new interface driver ftdi_sio
[ 51.300088] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
...
and lspci:
...
Bus 001 Device 006: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)
...
The settings for the mac and linux machine are identical. On both I use arduino 1.0.5. Both do see the correct serial port.
I've seen many posts in this forum with similar problems, but have yet to find one with a solution that works for me. Holding reset, or clicking it just before uploading does not work. As suggested in some forums I have tried with removing brltty to no avail. I have tried uploading with the Arduino IDE, Eclipse with AVR plugin and AVR via command-line. None will work. I've tried it on different machines as well with different versions of ubuntu, and uploading works in none of them. Adding -c arduino to avrdude command doesn't do the trick either. Any ideas on how to fix this?
My user is part of the dialout group, and I can upload to other arduino boards (like duemilanove) without problems.
This question was originally asked here: http://forum.arduino.cc/index.php?topic=244363
You mentioned Ubuntu; are you doing this as a normal user?
If so, you may need to add your account to the correct group, the serial port device belongs to.
You can do that like this:
sudo usermod -a -G dialout yourself
then (easiest) logout and log back in again.
However, it is possible that it is called something other than dialout in the latest Ubuntu, I haven't checked. I can confirm it is still dialout here on Debian Wheezy.
(this is a little odd, though, if it works; usually you get a permission error instead...)
I know this is quite an old question, but in addition to the dialout group problem I've had issues with ModemManager interrogating anything that looks like a serial port (and screwing up programmers in particular because they're not expecting those bytes). I don't know if that's what's happening in your case but it's worth a shot for others who end up here.
I just removed it entirely (which is a large hammer, probably temporarily disabling it is best...):
sudo apt-get remove modemmanager
If you want to try disabling it, maybe:
sudo systemctl stop ModemManager.service

Resources