Failure running Overtone and SuperCollider - linux

I can't get overtone to work with supercollider server, I'm following the getting started guide at https://github.com/overtone/overtone/wiki/Getting-Started, I've got Jack audio server running through qjackctl, then I ran SuperCollider with scsynth -u 8888 which produced the following output:
Found 12 LADSPA plugins
JackDriver: client name is 'SuperCollider'
SC_AudioDriver: sample rate = 48000.000000, driver's block size = 1024
SuperCollider 3 server ready.
Zeroconf: registered service 'SuperCollider'
then in the clojure repl I connect to SC server:
(connect-external-server 8888)
then when I run (definst foo [] (saw 220))
I get the following error:
CompilerException java.util.concurrent.TimeoutException: deref! timeout
error. Dereference took longer than 5000 ms whilst blocking until the
following node has completed loading: #<synth-group[loading]: Inst foo
Container 41>, compiling:(form-init1483192646581877285.clj:131:7)
and scsynth outputs FAILURE IN SERVER /g_new Group 31 not found
also if I try (demo (sin-osc)) I get the error FAILURE IN SERVER /s_new Group 7 not found
although if I run using sclang:
s.boot;
{ SinOsc.ar(440, 0, 0.2) }.play;
it does produce a sound.
I'm running Manjaro Linux using the Linux 4.9.27 real time Manjaro kernel
and an HDA Intel PCH sound card.

Related

Tensorflow error when used as Docker baseimage

Hi i am using below as my Docker image for fastapi application
FROM tensorflow/tensorflow:latest
when i run docker its running but i am getting this error
2021-06-23 23:31:50.516749: F tensorflow/core/lib/monitoring/sampler.cc:42] Check failed: bucket_limits_[i] > bucket_limits_[i - 1] (0 vs. 10)
qemu: uncaught target signal 6 (Aborted) - core dumped
[2021-06-23 23:31:50 +0530] [1] [WARNING] Worker with pid 2697 was terminated due to signal 6
and when i call api, i am not getting response, does it take time for api call or can you please tell me where it is wrong
I am guessing you are using a Mac with a M1 chip as This is a qemu bug, which is the upstream component we use for running Intel containers on M1 chips, this issue hasn't been solved yet. I suggest you can try and build TensorFlow for aarch64 Linux from source.

Error when running glxgears but xclock and xeyes work from Linux server with XForwarding on local OSX machine

I am trying to run glxgears or glxinfo from a server and I am receiving the following error:
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 149 (GLX)
Minor opcode of failed request: 3 (X_GLXCreateContext)
Value in failed request: 0x0
Serial number of failed request: 25
Current serial number in output stream: 26
My server is a Linux server and my local machine is OS X. However, I have tried running the same thing on a Linux machine and I am receiving the same error. I can run xeyes and xclock on the server and see the window pop up locally. If I saw nothing then I would think XForwading wasn't working at all, but since xeyes and xclock work then I am not sure what is going on.
What could be causing the BadValue (integer parameter out of range for operation) error?
In order to fix this issue I downgraded Xquartz from 2.7.11 to 2.7.8. For some reason the newer version of Xquartz doesnt work...

NWJS (Node Webkit) app is not responding on Linux systems when I use it with Web Workers

NWJS Version: v.0.32.1 (Tested on different 0.31 versions also and 0.32.beta)
Operating System: Linux only. Tested on Ubuntu 16.04 LTS x64 and Elementary OS 0.4.1 Loki x64
Expected behaviour
The program must respond.
Actual behaviour
The program not responding and if I break it (Ctrl + C) i seen in console that messages:
[14399:14410:0802/142733.750943:ERROR:broker_posix.cc(104)] Error sending sync broker message: Broken pipe (32)
[14399:14410:0802/142733.761023:ERROR:broker_posix.cc(104)] Error sending sync broker message: Broken pipe (32)
[14399:14409:0802/142733.761203:ERROR:broker_posix.cc(104)] Error sending sync broker message: Broken pipe (32)
[14399:14409:0802/142733.761402:ERROR:broker_posix.cc(104)] Error sending sync broker message: Broken pipe (32)
[14399:14409:0802/142733.761801:ERROR:broker_posix.cc(104)] Error sending sync broker message: Broken pipe (32)
[14399:14410:0802/142733.761896:ERROR:broker_posix.cc(104)] Error sending sync broker message: Broken pipe (32)
But if I'am using nwjs-builder-phoenix and running SDK - working correctly.
How to reproduce
Prepare
Download and extract fake data to parsing: https://github.com/trofivan/myq-jobs-archive-parser/releases/download/v0.1.0/fake-data-big.zip
git clone https://github.com/trofivan/myq-jobs-archive-parser.git
cd myq-jobs-archive-parser
npm i
Working correctly (only with nwjs-builder-phoenix SDK)
npm start
In the opened window click Select folder to parse
Select folder with fake data
Wait some time while data will have parsed.
Use filters
Close the program
Working not correctly
npm run build.dist
cd dist/myq-jobs-archive-parser-0.1.3-linux-x64/
./myq-jobs-archive-parser
Select folder to parse and waiting some time.
The program does not respond.
Close program (Ctrl + C or [x] on the window) and see console output:
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
[16012:16023:0802/145405.677499:ERROR:broker_posix.cc(104)] Error sending sync broker message: Broken pipe (32)
[16012:16023:0802/145405.678176:ERROR:broker_posix.cc(104)] Error sending sync broker message: Broken pipe (32)
[16012:16012:0802/145405.679403:ERROR:broker_posix.cc(104)] Error sending sync broker message: Broken pipe (32)
[16012:16012:0802/145405.679587:ERROR:command_buffer_proxy_impl.cc(100)] ContextResult::kFatalFailure: AllocateAndMapSharedMemory failed
killall exe - to stop the process
PS:
If download nwjs from the official website, working not correctly with SDK version also.
On Linux system program not responded when comes to the game Web Worker: https://github.com/trofivan/myq-jobs-archive-parser/blob/master/src/middlewares/fetchJobs.js
When program not responding I'm can not open Chrome dev tools and get more info.

Raspberry Pi: IR LED works, but irsend does not transmit any IR code

I installed the current lirc package (0.9.0~pre1-1.2) on a Raspian jessie (no pixel) (everything updated and upgraded) and connected to the (lirc default) GPIO ports:
to gpio port 17 - an IR LED via transistor etc
to gpio port 18 - an IR receiver nodule
The receiver part works perfectly:
mode2 command receiving raw data from transmitter
the IR code recognition of previously recorded keys works
However, the IR LED only works only while lirc is not involved:
a shell script can switch the IR LED on and off with no problem
The only thing that doesn't work:
irsend does not make the IR transmitter emit anything, however no error message is shown
So the hardware, especially the IR LED is definitely working, while lirc cannot make the LED emit any configured IR code.
Please note that this seems to be a duplicate of
stackoverflow: irsend is not giving errors, but does not send signal on Raspbian
Unfortunately it is not. The "solution" provided there was placing the data for /etc/modules into the file /etc/modules-load.d/lirc_rpi.conf. I tried that as well, but it makes no difference.
Any help is greatly appreciated!
Configuration data follows - if any other data is required, I'd be happy to add it! TIA!
System and lirc Configuration
Extract fom: /boot/config.txt
dtoverlay=lirc-rpi,gpio_in_pin=18,gpio_out_pin=17,debug=on
Extract of: /etc/modules
lirc_dev
lirc_rpi gpio_in_pin=18 gpio_out_pin=17
(not sure if that is necessary at all, does not make a difference if this is not configured!? Any hint apppreciated)
All active entries in: /etc/lirc/hardware.conf
LIRCD_ARGS="--uinput"
DRIVER="default"
DEVICE="/dev/lirc0"
MODULES="lirc_rpi"
LIRCD_CONF=""
LIRCMD_CONF=""
Some system output
1) The driver is loaded, output of following command right after boot, output of: dmesg | grep lirc
lirc_dev: IR Remote Control driver registered, major 245
lirc_rpi: module is from the staging directory, the quality is unknown, you have been warned.
lirc_rpi: to_irq 178
lirc_rpi: auto-detected active low receiver on GPIO pin 18
lirc_rpi lirc_rpi: lirc_dev: driver lirc_rpi registered at minor = 0
lirc_rpi: driver registered!
input: lircd as /devices/virtual/input/input0
lirc_rpi: Interrupt 178 obtained
2) the service is started and running, output of: systemctl status lirc
? lirc.service - LSB: Starts LIRC daemon.
Loaded: loaded (/etc/init.d/lirc)
Active: active (running) since Mo 2017-06-12 20:04:03 CEST; 2h 58min ago
Process: 377 ExecStart=/etc/init.d/lirc start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/lirc.service
+-437 /usr/sbin/lircd --driver=default --device=/dev/lirc0 --uinput
3) the modules are loaded, output of: lsmod | grep Module;lsmod | grep lirc
Module Size Used by
lirc_rpi 8453 3
lirc_dev 10211 1 lirc_rpi
rc_core 23776 1 lirc_dev
I followed the troubleshooting steps in the (outdated) manual at http://aron.ws/projects/lirc_rpi/
to get some more information.
Output of: cat /sys/kernel/debug/gpio
gpiochip0: GPIOs 0-53, parent: platform/20200000.gpio, pinctrl-bcm2835:
gpio-35 ( |? ) in hi
gpio-47 ( |? ) out lo
I have seen that output also in this case:
raspberrypi.stcakexchange: LIRC won't transmit (irsend: hardware does not support sending)
This user is as irritated by that output as I am - can somebody please tell why gpio-35 and gpio-47 are listed here? shouldn't it be gpio-17 and gpio-18?
Output of: cat /proc/interrupts | grep lirc
178: 875 pinctrl-bcm2835 18 Edge lirc_rpi
This matches the dmesg output on having obtained interrupt 178
Any other dmesg output of lircd, no matter what action, is repeatedly (most likely due to the debug option set) only
lirc_rpi: SET_SEND_CARRIER
lirc_rpi: in init_timing_params, freq=38000 pulse=13157, space=13158
lirc_rpi: SET_SEND_DUTY_CYCLE
lirc_rpi: in init_timing_params, freq=38000 pulse=13157, space=13158
Having restarted testing again after some time for to build up a test copy of the circuit, the problem occurred again. And now, after some more month of much testing, having asked lots of people for help (no one could help), even having purchased and built up a cheap mini USB oscilloscope kit for to examine the hardware further, I finally found the solution.
Long story short: everything in the configuration was correct, and all of the attached hardware was fine. The problem was the testing script - see my remark on
"a shell script can switch the IR LED on and off with no problem"
and as I did not put it in the above description, nobody could have found the solution myself....
The script uses the pseudo files in /sys/class/gpio, see an example here:
raspberry-projects.com: IO pin control from the command line
At the end of the script a command writes to /sys/class/gpio/unexport for cleanup purposes, and this step seems to reset a GPIO port to always end up in the state of being configured for input. As a result LIRC is not longer able to control this GPIO port, since it seems to configure the GPIO port for output only during system boot, and after that always expecting the port to be in that state.
I tracked the problem down to this point by using the gpio utility from the wirinpi package (install with sudo apt-get wiringpi), executing gpio readall and checking for differences.
The time when everything suddenly worked again, I simply may have fogotten about to run my testscript before testing LIRC, which I otherwise always did...
Luckily the problem with the port configuration can easily be fixed without having to reboot the system. Again I use the gpio utility to reset reset the used port for output, where in the below example
the default output port 17 for LIRC is used and
the parameter -g lets the utility use the ordinary GPIO port numbering and not that very different one of the wiringpi package and library
Here is the command, after having executed this last in my test script, LIRC can properly send IR codes again:
gpio -g mode 17 out

Adb protocol fault (couldn't read status)

I am using Mac OSX El Captain with Android Studio 2.2.
Android Studio start to don't show Android devices suddenly. I try to kill adb server and start it again and this errors appear on terminal.
List of devices attached
daemon not running. starting it now on port 5037 *
adb E 1165 84563 usb_osx.cpp:307] Could not clear pipe stall both ends: e0004051
adb E 1165 84563 usb_osx.cpp:289] Could not find device interface
daemon started successfully *
When I try to kill server twice for understanding the issue it gives this error message:
error: protocol fault (couldn't read status): Connection reset by peer
Try restarting your Mac and devices. I ran into a similar error and restart got rid of it :)

Resources