I am writing some programs using very simple/low-level ALSA audio output,
essentially doing something like:
snd_pcm_open(&handle, device, SND_PCM_STREAM_PLAYBACK, 0);
snd_pcm_set_params(handle, SND_PCM_FORMAT_S32, SND_PCM_ACCESS_RW_INTERLEAVED, width, sampleRate, 0, (width * NUM_PERIODS_PER_BUFFER * MICROSECONDS_IN_SECOND) / sampleRate);
and then, in a loop:
snd_pcm_writei(handle, buff, frames.frames_in_period);
This works as expected playing sound on local (Linux) loudspeakers.
Since this Linux machine is a headless server I need to move "somewhere else" (together with loudspeakers,of course) and access it through ssh (MobaXTerm on windows, actually) making it impossible to hear output.
Question is: is there a simple way to redirect audio over ssh tunneling?
I have seen trx, but it seems to be unavailable on windows.
It would be very important to avoid modifying playing program (changing output device is OK)
Related
I know there are a bunch of blogs explaining how to set up the wifi headless on the raspberry pi. I have followed them and they worked, once. But I had to format the sd card, and re-do it and it doesn't connect to the WiFi anymore.
I use the RPI Imager to write the OS. (Note I've also tried with the advanced option pressing Ctrl + Shift + 10, and set up the wifi, ssh over like this. After writing it, the verification returned an error that couldn't create a FAT32 partition).
Then I created a blank ssh file inside the sd card (boot) to allow the ssh connection.
Then I created the wpa_supplicant.conf file containing this:
country=CZ
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
ssid="NETWORK-NAME"
psk="NETWORK-PASSWORD"
}
Then I eject the sd card, insert it in the raspberry pi and it doesn't connect to the wifi.
I know that the Raspberry pi, and the wifi connector work well. So it must be something that I'm misssing.
I'm honestly desperate at this point since I have spent more than 10 hours just trying to connect to the WiFi. I have formated and re-installed the Raspberri-OS a bunch of times already, and tried as many tutorials as I could find.
There's not really a single universal answer to your question, so at the risk of telling you a bunch of things you already tried, here's my exhaustive list of stuff to try/consider:
If you're using Ubuntu you probably have to use netplan - see here for some instructions https://askubuntu.com/questions/1143287/how-to-setup-of-raspberry-pi-3-onboard-wifi-for-ubuntu-server-with-netplan
Don't forget your key_mgmt field (use the value relevant to your wifi):
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=CA
network={
ssid="NETWORK_SSID"
psk="PSWD"
key_mgmt=WPA-PSK
}
If you can ssh into with a wired connection, and are using Raspian, you may find using raspi-config easier (sudo raspi-config, then System Options > S1 Wireless LAN).
Now we get into the "I already checked that five times" part of the list:
a)if you're using Ubuntu/netplan, ensure you're using the correct interface id by doing ifconfig - should be wlan0, but you never know
b)ensure you have your SSID correct - you can do sudo iw wlan0 scan to find all the networks in reach and double check the SSID. Watch out for weird quotation marks (e.g. 'smart' quotes), elongated dashes and stray spaces - in particular if you have pasted the SSID and password from elsewhere
c) ensure your SSID, password and key setting is correct by checking a different device
d) ensure you are looking for the right IP address on your LAN - you can do a sudo nmap -sn 192.168.1.0/24 and your Pi devices should show up looking like:
Nmap scan report for 192.168.1.68
Host is up (0.00044s latency).
MAC Address: B8:27:EB:8B:73:AD (Raspberry Pi Foundation)
Remember that if using DHCP, your Wifi and Wired connections will get different IP addresses - if using static for Wired, you'll also likely get a DHCP address for your wireless interface.
If you keep failing using the same Raspian image, try something different, just to isolate the problem - e.g. try Ubuntu if you keep failing with Buster (or vice versa)
Finally, some more general advice about what to do when you're just so frustrated with a problem that you've spent way too much time on - write out a 'proof' of why what you're trying to do is impossible, explaining line by line how you've done exactly the steps that are supposed to work. This is my method of last resort, and currently has a 100% success rate - when I try to explain why the thing is impossible, I realize what I didn't do, overlooked, or did wrong.
Actually, I solved this by following this blog https://weworkweplay.com/play/automatically-connect-a-raspberry-pi-to-a-wifi-network/?fbclid=IwAR2QckXB5XMPLCttnyBDUWv-MgxFsk0utfih4FHpF1za4OzH-9h-SKgR0GM and adding some stuff to the /etc/network/interfaces/
I'm trying to capture desktop and stream it live in an Apache server using DashCast. It captures and plays correctly when I do it on demand, however when I do it live and then play with MP4Client it shows only a black screen, not even getting any error message while capturing it. The commands I’m using are:
DashCast -vf x11grab -vres 1280x720 -v :0.0 -npts -live -out /public_html/
And then I play with:
MP4Client http://localhost/vitor/dashcast.mpd
Which results in the following output:
MP4Client http://localhost/vitor/dashcast/dashcast.mpd
Using config file in /home/vitor directory
System info: 11948 MB RAM - 8 cores
Modules Found : 36
Loading GPAC Terminal
[Thread MediaManager] Couldn't set priority(2) for thread ID 0x9b55a700
[Thread MediaManager] Couldn't set priority(2) for thread ID 0x9b55a700
Terminal Loaded in 35 ms
Opening URL localhost/vitor/dashcast/dashcast.mpd
[DASH] Slight drift in UTC clock at time 2015-08-05T12:38:45Z: diff AST - now 3563501 ms
Service Connected
So what am I doing wrong? The client apparently connects correctly to the server, open the player but then it doesn't show anything on screen. I'm using Ubuntu 14.04 with GPAC version 0.5.0.
[DASH] Slight drift in UTC clock at time 2015-08-05T12:38:45Z: diff AST - now 3563501 ms
This message indicates that there is a difference ('slight' is a wrong word here given the actual difference !) between the UTC time indicated in the MPD in the availabilityStartTime attribute and the current time that MP4Client uses to compute which segment to fetch. This is only relevant for live because for on demand, all segments are assumed to be available all the time.
MP4Client uses different strategies to determine the 'current' time. The system time on the client may be different from the system time on the server, if they are using different NTP servers for instance. System time is not reliable. So MP4Client tries to get the time from the server. It first tries to use a specific HTTP "Server-UTC" header that the server may set. See for example this code. If this header is not set, it looks at the HTTP "Date" Header, even if it's not very precise. In your case, your HTTP server probably has a time configuration that does not match the system time. You can tell MP4Client to stop using the server information and to rely on its system time. Since you are using client and server on the same machine, that should work. The documentation of that option is here. For that, use:
MP4Client http://localhost/file.mpd -opt DASH:UseServerUTC=no
Alternatively, you can try to play the MPD locally without going through the web server.
MP4Client file.mpd
If that is not working, open an issue on GPAC's GitHub providing as much information as possible, in particular the result of MP4Box -version.
I just encountered and circumvented a problem in Matlab, but I'm still wondering why this happens, and I also want to leave the information here for future reference.
In Matlab's Parallel Computing Toolbox, the command matlabpool local starts a local pool of Matlab workers which are then used transparently to speed up commands like parfor by distributing processing onto the different CPU cores. I tried to do so on a Linux machine which I connected to through ssh from my home Linux computer. I used ssh without X forwarding because the script I wanted to run only computes and saves the result, but does not produce graphical output.
The problem: matlabpool hung forever, without any indication of the cause. I restarted the remote machine, restarted Matlab, checked for license problems, without result.
The problem was resolved however when I closed ssh and logged back in, this time including the -X option for X11 forwarding – even though then I started Matlab with the -nodesktop option.
Does anyone have an idea why matlabpool on Linux appears to depend on access to X11?
Even though matlabpool starts and communicates with background headless workers, you can still create figures and plots and print/export them as images inside the parfor parallel loop. The following is a valid use case:
matlabpool(..)
parfor i=1:4
plot(..)
print(...)
close(..)
end
To me this suggests that background workers will still depend on graphics capabilities to generate the invisible plots in memory (maybe it's using virtual framebuffers and such). Of course this is just speculation on my part :)
EDIT:
Just to be sure here, can you try the following sequence of commands:
[client]$ ssh -v -x user#server # X11 forwarding disabled
[server]$ unset DISPLAY # clear $DISPLAY variable
[server]$ nohup matlab -nodesktop -nodisplay -noFigureWindows -nosplash \
-r "myscript; quit;" 2>&1 < /dev/null &
Where the script contains a simple parallel test like:
myscript.m
parpool('local',2)
smpd
fprintf('hello from lab#%d', labindex);
end
delete(gcp('nocreate'))
If MATLAB still hangs, try adding the -debug start option:
matlab -debug starts MATLAB and displays debugging information that can be useful, especially for X based problems.
I'm working on an iMX23 cpu with linux-2.6.35.3 and wondering if this is even possible to implement.
I can build g_serial and g_multi and use the serial port function, which uses /dev/ttyGS0.
Do I just have to change [console=ttyS0] to [console=ttyGS0] on the kernel command line?
Thanks
Yes, it should be that simple. Just change your kernel command line to "console=ttyGS0,115200" or similar. You'll find it even works with usb ports ie "console=ttyUSB0" for example.
It seems you can easily add another console port just by adding another setting in [/etc/inittab]
::respawn:/sbin/getty -L ttyAM0 115200 vt100
::respawn:/sbin/getty -L ttyGS0 115200 vt100
Adding another line as above will enable you to use USB serial as console too(/dev/ttyGS0).
I have this USB Relay:
http://www.ebay.com/itm/5V-USB-Relay-2-Channel-Programmable-Computer-Control-For-Smart-Home-/141097843081?pt=LH_DefaultDomain_0&hash=item20da163989
Al I need is to send close/open to the device (to turn on & off an LED light)
How can I do that using C# or C++?
Thanks
Boaz
Here's what you need (tested on Linux) :
HIDAPI from http://www.signal11.us/oss/hidapi/
USBRELAY from https://github.com/darrylb123/usbrelay/blob/master/README.md
Use it like :
usbrelay ZG4HU_1=1
usbrelay ZG4HU_1=0
to switch the first relay on and off. ZG4HU_2 addresses the second relay and without arguments you even get the relay status.
-- Hans
The 26484 26483.rar is what I needed for Windows. .exe files for graphic and for command line for testing and .dll for my own development.
Found here: http://files.elektroda.net/794975,26484++26483+usbrelayextlib.html