I have a fresh instalation of supercollider 3.10.0. When I run:
s.boot;
{ [SinOsc.ar(440, 0, 0.2), SinOsc.ar(442, 0, 0.2)] }.play;
I should hear something right? But I hear no sound, while all other sounds apps do have sound. I tried this solution: No sound from SuperCollider with Jack2 but it didn't work for me. What can I do to find the problem?
My log says
Booting server 'localhost' on address 127.0.0.1:57110.
jackdmp 1.9.12
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2016 Grame.
Copyright 2016-2017 Filipe Coelho.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK server starting in realtime mode with priority 10
self-connect-mode is "Don't restrict self connect requests"
audio_reservation_init
Acquire audio card Audio0
creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 32bit integer little-endian
ALSA: use 2 periods for playback
JackDriver: client name is 'SuperCollider'
SC_AudioDriver: sample rate = 48000.000000, driver's block size = 1024
JackDriver: connected system:capture_1 to SuperCollider:in_1
JackDriver: connected system:capture_2 to SuperCollider:in_2
JackDriver: connected SuperCollider:out_1 to system:playback_1
JackDriver: connected SuperCollider:out_2 to system:playback_2
SuperCollider 3 server ready.
JackDriver: max output latency 42.7 ms
Requested notification messages from server 'localhost'
localhost: server process's maxLogins (1) matches with my options.
localhost: keeping clientID (0) as confirmed by server process.
Shared memory server interface initialized
-> Synth('temp__0' : 1000)
Is there anything suspicious? Thank you!
Related
We are using two USRPs and GNU Radio Companion to build an OFDM radar. The first USRP is the N210 which is used as a transmitter through its Tx/Rx port. The second USRP is N200 which is used as a receiver through its Rx2 port. They are connected together through the so-called MIMO cable to synchronize them. The N210 is connected to the host PC through the gigabit Ethernet cable. The samples that feed the transmitter USRP comes from a block "File Source", and the samples that are collected from the receiver USRP goes to a block "File Sink".
Initially, an external loopback cable is used between the Tx/Rx port of N210 and the the Rx2 port of the N200. Whenever we run the flowgraph, we expect that for every sample that is transferred from the File Source to N210, there should a corresponding sample with somehow same value that comes from N200 to File Sink. However, we have noticed that the N200 produces a stream of random samples before the awaited samples start to appear!!! The length and the values of this stream of random samples varies each time we re-run the flowgraph!!! Of course this issue constitutes an obstacle for our application because in radar the range of the target to be detected is estimated depending on the delay time. The latter is computed from the number of noise samples at the receiver that precedes the reception of the actual transmitted samples.
The question is: How can we guarantee or force the receiving USRP (N200) not to receive any sample before the transmitter USRP (N210) starts to transmit the required samples? Should not this be the task of GnuRadio?!!!! or we have to do something in GnuRadio to force this to happen?
thnx
We are using two USRPs and GNU Radio Companion to build an OFDM radar. The first USRP is the N210 which is used as a transmitter through its Tx/Rx port. The second USRP is N200 which is used as a receiver through its Rx2 port.
This sounds like you're reproducing my 2013 bachelor thesis!
Whenever we run the flowgraph, we expect that for every sample that is transferred from the File Source to N210, there should a corresponding sample with somehow same value that comes from N200 to File Sink.
No, that would only work when you start and stop both USRPs using the same command times and the same number of samples to be acquired.
However, we have noticed that the N200 produces a stream of random samples before the awaited samples start to appear!!!
Well, over-the air delay, and the state in the DSP chain. This is expected. Use timed commands to make the timing deterministic, and you'll know how many samples to ignore.
i have to try get a class-map bit rate traffic from router cisco ios xe
i get a oid from cisco
https://www.cisco.com/c/en/us/support/docs/ip/simple-network-management-protocol-snmp/119031-technote-router-00.html
the OID of postbitrate is give me only Gauge32
+-- -R-- Gauge cbQosCMPostPolicyBitRate(11)
so when my police traffic is under number : 4,294,967,295 , i get i correct value
but when the traffic go up of 4,294,967,295 bit
of example my real policy-traffic bps is :4,665,204,000
and when i try to get in by snmp i get value 376,176,704 (9 dig only)
snmpwalk -v2c -c ABCDED X.X.X.X iso.3.6.1.4.1.9.9.166.1.15.1.1.11
iso.3.6.1.4.1.9.9.166.1.15.1.1.11.1298180580.131072 = Gauge32: 376176704
so how to convert a Gauge32 correct value when my traffic is go up of 4,294,967,295 bps
i know is 32-bit only can Handle maximum 4,294,967,295
but in cisco mib . and for policy-map postbitrate , is only return Gauge32 ...
This is called the "SNMP counter wrap" condition (you can google it).
This is detailed in this Cisco page
https://www.cisco.com/c/en/us/support/docs/ip/simple-network-management-protocol-snmp/26007-faq-snmpcounter.html
The only way for a management app to detect it is if the counter is smaller
than previously retrieved, at least one counter wrap occurred and you add 2^32-1 to
the latest value.
The alternative is to find the 64-bit counter, usually defined in a newer MIB.
I have been working on my ANC project. For this I have two microphone inputs and one loud speaker output, but initially I am using single microphone and dspStreamingPassthrough to pass microphone input to loud speaker. Here is my code
% Initialization
numIterations = 500;
% Construct sources (for all inputs)
src1 = dsp.AudioRecorder('DeviceName','Mikrofon (USB-Audiogerät)','NumChannels',1);
% Construct sinks (for all outputs)
sink1_1 = dsp.SpectrumAnalyzer('SampleRate',44100, ...
'PlotAsTwoSidedSpectrum',false, ...
'ShowLegend',true);
sink1_2 = dsp.TimeScope('BufferLength',44100, ...
'SampleRate',44100, ...
'TimeSpan',1, ...
'ShowLegend',true, ...
'ShowGrid',true, ...
'YLimits',[-0.5 0.5]);
sink1_3 =
dsp.AudioPlayer('BufferSizeSource','Property','BufferSize',1024,...
'QueueDuration',0,'OutputNumUnderrunSamples',true);
sink1_3.DeviceName = 'Lautsprecher (USB-Audiogerät)';
% Stream processing loop
clear dspStreamingPassthrough;
for i = 1:numIterations
% Sources
in1 = step(src1);
% User Algorithm
out1 = dspStreamingPassthrough(in1);
% Sinks
step(sink1_3,out1);
step(sink1_1,out1);
step(sink1_2,out1);
nUnderrun=step(sink1_3,out1);
end
% Clean up
release(src1);
release(sink1_1);
release(sink1_2);
I am using Windows DirectSound Audio driver ( I cannot use ASIO driver as I cannot access individual audio devices names. ! ) Now I have the audio latency of 1.2 seconds i.e if I say ''hello'' in microphone now, after 1.2 seconds speaker is saying ''hello''(this is absolutely with out any audio input data processing just 'dspStreamingPassthrough'). How to reduce this incredible delay ?
For my project of 1 meter length pipe(air duct), I should be able to process the data in 1.7 msec or less !! I have tried with lowest 'BufferSize' and lowest 'QueueDuration' possible !!
What other parameters can influence to speed up this process? Is it possible with MATLAB or not ?
PS: -sorry for whole code. -I am using a cheap quality Sound card (7 euros)
DirectSound has way higher latency than ASIO because DirectSound is not suited for low-latency apps. DSP System Toolbox does not support WASAPI yet.
The latency performance of these objects was greatly improved starting in 15a. I am not sure which version you are running but try and upgrade to 15a or higher.
As for tuning your latency, try the following:
* Set the Queue Duration property to 0 seconds for both player and recorder.
* For the recorder, match the SamplesPerFrame and BufferSize property.
* For the player, ensure that the size of the data matches the BuferSize property.
The BufferSize property is the size at which the sound card operates.
If you get drops, increase the BufferSize value. There can be many reasons for the drops:
* The algorithm you are running is not faster than BufferSize/SampleRate
* The soundcard is not able to operate at this BufferSize. Some sound-cards allow you to modify this when using ASIO.
* Limitation of the player/recorder objects.
Hope this helps.
Dinesh
I am trying to connect to Atmega328P chip through eXtreme Burner. I used 22pf capacitors and 10K pull for reset.
I am able to read the chip if I use 8 MHz Crystal. But cannot read if I connect 16MHz crystal. When I looked at the datasheet, it says fuse bits are same for 8 MHz and 16 MHz. I get "Power On Failed" error message with 16 MHz. I am using USBASP programmer.
Please note: With 8 MHz crystal, though I am able to read the device, I get error message "Incorrect Chip Found! Continue". If I press OK, it reads the data. The fuse bits read using 8 MHz crystal are: Low-- FF, High - DE, Extended -- FD, Lock Fuse - CF and Calibration - FFFFFFB1
What could be the issue?
Attached screen shots in the link
http://www.filedropper.com/extremeburnererrors
Its not in your settings then, so it must be in the setup of your hardware. Try different capacitor values. If I remember correctly, you have to vary the value of the capacitors as the frequency of your crystal varies. Also you have to take in to account the added inductance and capacitance of the breadboard or pcb and solder. So I would suggest just trial and error with different capacitor values.
I am using Arduino Leonardo to transmit an string to a wifi module. The format of command that wifi module can recognize is:
AT60,1,content to a server
I am using an virtual server(TCP/IP Builder) to test the content I can received.
Here is the content I want to send:
smart/device/deviceCmd?userId=1010002003&deviceId=A00019999990002&cmd=ON
Since I try to send it again and again, I use a loop to send it. In the virtual server side, the content I got is:
smart/device/deviceCmd?userId=1010002003&devceId=A00019999990002&cmd=ON
smart/device/deviceCmd?userId=1010002003&devceId=A00019999990002&cmd=ON
smart/device/deviceCmd?userId=1010002003&dviceId=A00019999990002&cmd=ON
smart/device/deviceCmd?userId=1010002003&eviceId=A00019999990002&cmd=ON
smart/device/deviceCmd?userId=1010002003&devieId=A00019999990002&cmd=ON
smart/device/deviceCmd?userId=1010002003deviceId=A00019999990002&cmd=ON
smart/device/deviceCmd?userId=1010002003&dviceId=A00019999990002&cmd=ON
smart/device/deviceCmd?userId=1010002003&dviceId=A00019999990002&cmd=ON
smart/device/deviceCmd?userId=1010002003&deiceId=A00019999990002&cmd=ON
smart/device/deviceCmd?userId=1010002003&dviceId=A00019999990002&cmd=ON
This is the QUESTION: There exist one terrible mistake in the content I received, which is the deviceId part never correct. It's so weird.
Here is part of related code:
//In Uart.cpp
//These three lines can sent a formatted string as "AT60,1,content"
Serial1.write("AT60,");
Serial1.write(channelID); //channel ID = 1 here
Serial1.write(reportIsFire, 76);
//In Uart.h
//Definition of the string I need to send, which has 76 characters.
char reportIsFire[76] = ",smart/device/deviceCmd?userId=1010002003&deviceId=A00019999990002&cmd=ON \n";
Here is few background of this application:
I am using Arduino 1.5.8 IDE with VisualStudio
Since the serial buffer of Arduino is only 64 Bytes, I have already
change the buffer size to 128 Bytes in "HardwareSerial.h" to send
out this large string.
The baud rate is 115200 and I am using Serial 1. I have used Serial 1
to transmit few other characters and it works fine.
I will appreciate that If you have any idea about this question.
I am betting that the serial baud rate of the Arduino is not 100% correct. Increasing the buffer size will not matter if the data is being lost due to a timing issue in the physical link.
I'd recommend double-checking the code that initializes the serial baud rate generator. It may be possible to get a closer rate to 115,200 by either adjusting the available settings, altering the main clock speed (if possible), implementing some form of flow control, or all of the above.
In extreme cases, you may consider using a special-frequency oscillator. Many Microchip PICs use an internal or external 4MHz or 8MHz crystal, but this can produce far too much timing error for lengthy serial transmissions at high speed. In that case, something special, like a 7.3728MHz crystal can be used, bringing the accuracy to exactly 100% (at least on some PIC devices.)
Lastly, another consideration is if any pre-emptive code is running on the device, such as interrupts or timers which could inadvertently interfere with the serial output.
I don't have an answer, but I suspect the most likely problem is that the Wifi card can't read characters at a sustained 115200 baud rate. If possible, set the Wifi baud rate and the Arduino Serial.begin() to a lower rate, such as 57600 or 19200.
If the Arduino baud rate was simply inaccurate, I'd expect to see the problem appearing at random locations in the string, rather than about 40 characters in.