Problem: How can I detect when the audio UAC1 gadget is used from a host device?
Background: I created a USB audio gadget using USB Audio Class 1 (UAC1) to send/receive audio over USB from a Linux device to/from a Windows host. The gadget is already working and Windows detects the device as an audio in and output. I am also able to send and receive audio over the gadget using alsa and jack.
Detailed Problem: I'm trying to connect two different audio devices with Jack to route an incoming signal from audio-device-1 to the output of audio-device-2. To do this, I'm working with the virtual wiring of Jack. This works already fine, but I run into the problem that if the gadget device is not actively selected as audio in and output in a DAW or other program on the host computer (e.g. Windows), Jack gets a "poll time out" error and the virtual wiring has to be restarted.
$ jackd -r --name default -d alsa --device hw:2 -r 48000 -p 64 -n 2
jackdmp 1.9.17
....
creating alsa driver ... hw:2|hw:2|64|2|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 64 frames (1.3 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 24bit little-endian in 3bytes format
ALSA: use 4 periods for capture
ALSA: final selected sample format for playback: 24bit little-endian in 3bytes format
ALSA: use 4 periods for playback
ALSA: poll time out, polled for 2000981 usecs, Retrying with a recovery, retry cnt = 1
ALSA: poll time out, polled for 2000979 usecs, Retrying with a recovery, retry cnt = 2
ALSA: poll time out, polled for 2000982 usecs, Retrying with a recovery, retry cnt = 3
ALSA: poll time out, polled for 2000979 usecs, Retrying with a recovery, retry cnt = 4
ALSA: poll time out, polled for 2000988 usecs, Retrying with a recovery, retry cnt = 5
ALSA: poll time out, polled for 2000989 usecs, Reached max retry cnt = 5, Exiting
JackAudioDriver::ProcessAsync: read error, stopping...
I would like to solve this automatically e.g. via a shell script that detects when the gadget driver is requested by the host and I then start the virtual cabling with Jack.
For this it is necessary to be able to read whether the gadget driver is in use or not.
Is there any directory / file where I can detect, if the audio gadget device is in use?
Related
I am using a Packet Capturing and Analysis Tool named as Cisco Joy for generating network flows.
Here is the link: https://github.com/cisco/joy
So Joy is a Packet capturing and analysis tool which uses a configuration file to capture Packets on a network interface and return json files as output in a directory.
I have configured Cisco Joy with AF_Packet to generate the network flows.
So I have been trying to process the network packets using tcpreplay on a virtual network interface at a speed of 3 GBPS but Joy is not receiving the packets at the same speed.
Actual: 450889 packets (397930525 bytes) sent in 1.06 seconds
Rated: 374307598.1 Bps, 2994.46 Mbps, 424122.22 pps
Flows: 12701 flows, 11947.01 fps, 450298 flow packets, 591 non-flow
Statistics for network device: vth0
Successful packets: 450889
Failed packets: 0
Truncated packets: 0
Retried packets (ENOBUFS): 0
Retried packets (EAGAIN): 0
Packets Received from Cisco Joy: 260850
So Here tcpreplay sent over 400k packets but Cisco Joy received only around 260k.
I have changed the buffer size of the length in which the packets have been captured but still I didn't find any resolution from that so anyone have any clue about this?
I'm attempting to play a live stream on ChromeCast. The stream is thrown fine and starts playback appropriately.
However when I play the stream longer: somewhere between 2-15 minutes, the player stops playing and I get MediaStatus.IDLE_REASON_ERROR in my RemoteMediaClient.Callback.
When looking at the console logs from ChromeCast I see that 3-4 calls are failed. Here are the logs:
14:50:26.931 GET https://... 0 ()
14:50:27.624 GET https://... 0 ()
14:50:28.201 GET https://... 0 ()
14:50:29.351 GET https://... 0 ()
14:50:29.947 media_player.js:64 [1381.837s] [cast.player.api.Host] error: cast.player.api.ErrorCode.NETWORK/3126000
Looking at Cast MediaPlayer.ErrorCode Error 312.* is
Failed to retrieve the media (bitrated) playlist m3u8 file with three retries.
Developers need to validate that their playlists are indeed available. It could be the case that a user that cannot reach the playlist as well.
I checked, the playlist was available. So I thought perhaps the server wasn't responding. So I looked at the network calls response logs.
Successful Request
Stalled Request
Note that the stall time far exceeds the usual stall time.
ChromeCast isn't making these calls at all, the requests are simply stalled for a long time until they are cancelled. All the successful requests are stalled for less than 14ms (mostly under 2ms).
The Network Analysis Timing Breakdown provides three reasons for stalling
There are higher priority requests.
There are already six TCP connections open for this origin, which is the limit. Applies to HTTP/1.0 and HTTP/1.1 only.
The browser is briefly allocating space in the disk cache
While I do believe the first one should not be the case, the later two can be. However in both cases I believe the fault lies with cast.player.
Am I doing something wrong?
Has anyone else faced the same issue? Is there any way to either fix it or come up with a work-around.
I am currently trying to get Advertisement Packets from Bluetooth LE in Windows 10.
I am developing an Universal Windows Application, thus I am using JavaScript with the following code:
// Create and initialize a new watcher instance.
var watcher = new Windows.Devices.Bluetooth.Advertisement.BluetoothLEAdvertisementWatcher();
watcher.signalStrengthFilter.inRangeThresholdInDBm = -126;
watcher.signalStrengthFilter.outOfRangeThresholdInDBm = -126;
watcher.signalStrengthFilter.outOfRangeTimeout = 60000;
watcher.signalStrengthFilter.samplingInterval = 0;
watcher.scanningMode = 1;
watcher.addEventListener("received", onAdvertisementReceived, false);
These are my settings to get the most BLE ADV Packets.
In my scenario I have a BLE transponder sending an ADV packet every second, which I can verify on a linux-machine with WireShark.
Strangely I don't get all of these ADV packets with the Windows application.
I will get like 15-20 packets and then there is a 30-60s pause before getting other packets.
All devices (windows-machine, linux-machine and ble-transponder) are within a 1m radius. So I think I should get the same packets on the windows-machine like on the linux-machine, but I don't. Why is that? Are my settings wrong or is there a better way of getting ADV packets?
Thank you in advance.
See my answer at BLE Scan Interval Windows 10.
Basically, Windows instructs the BLE controller to scan for 18.125 ms and then to sleep for 100 ms. That's why you don't get all packets.
I'm using ffmpeg library to write to the rtsp stream.
It is working well when the rtsp url is correct.
But when this rtsp url is incorrect then it is stuck in avformat_write_header.
Is there any solution for this problem?
Thanks.
Please refer to following link:
[FFmpeg-user] How do I set a timeout for an RTSP source?
There are two timeout type of options for RTSP:
‘-timeout’
Set maximum timeout (in seconds) to wait for incoming connections.
A value of -1 mean infinite (default). This option implies the
‘rtsp_flags’ set to ‘listen’. ‘reorder_queue_size’
Set number of packets to buffer for handling of reordered packets.
‘-stimeout’
Set socket TCP I/O timeout in micro seconds.
Both ‘-timeout’ & ‘-stimeout’ do not work for me.
My solution [python code] is:
while True:
try:
check_call('ffmpeg -i <rtsp://your-input-stream-url> -frames:v 1 screenshot.jpg', shell=True, timeout=N) # try to get a screenshot if RTSP stream is OK
except TimeoutExpired as e:
logger.error('RTSP stream error') # send error message if timeout
break
Good luck.
Just my two cents here. Sometimes you are establising the connection and need to close it if there's no stream in N seconds. A simple -timeout option will switch your connection mode (may be unwanted) and they had some bug in older versions of ffmpeg that made -stimeout fail your purpose sometimes.
Here's one more timeout, the rw_timeout:
rw_timeout
Maximum time to wait for (network) read/write operations to complete, in microseconds.
As said, it is a network-related option, could be of use both with ffmpeg utils and from source code.
Using Andrew Rapp's XBee-API, how can I sample I/O data via a coordinator from more than two endpoints?
I have 17 Series 1 XBees. I have programmed one to be a coordinator (API mode = 2) and the rest to be endpoints. Using XBee-API I am sending a Force I/O Sample ("IS") remote AT command, unicast to each endpoint. This works perfectly well when there are up to two endpoints, but as soon as a third is added, one of the three always becomes non-responsive (times out with XBeeTimeoutException). It's not always the same physical unit that stops responding, but it is always the third one (for example, if I send Force I/O Sample to Device1, Device2, and Device3, Device3 will time out, and if I change the order to Device3, Device1, Device2, Device2 will time out.
If I set up more than three XBees, about 1 out of 3 will time out - but not every third one.
I've verified that the XBees themselves are fine. I've searched the Internet and Stack Overflow in particular to no avail. I've tried using a simple ZNetRemoteAtRequest. I've tried opening and closing the XBee coordinator serial connection once for all three devices, once per device, and once per program run. I've tried varying the distance between the coordinator and endpoints (never more than five feet apart). I've tried different coordinator configuration parameters (from the Digi documentation). I've tried changing out the XBee for the coordinator.
This is the code I'm using to send the Force I/O Sample request to each endpoint and read the response:
xbee = new XBee(); // Coordinator
xbee.open("/dev/ttyUSB0, 115200)); // Happens before any of the endpoints are contacted
... // Loop through known endpoint addresses
XBeeRequest request = new ZBForceSampleRequest(new XBeeAddress64(endpointAddress));
ZNetRemoteAtResponse response = null;
response = (ZNetRemoteAtResponse) xbee.sendSynchronous(request, remoteXBeeTimeout);
if (response.isOk()) {
// Process response payload
}
... // End loop and finally close coordinator connection
What might help polling I/O samples from more than two endpoints?
EDIT: I found that Andrew Rapp's XBee-API library fakes multithreaded behavior, which causes the synchronization issues described in this question. I wrote a replacement library that is actually multithreaded and correctly maps responses from multiple XBee endpoints: https://github.com/steveperkins/xbee-api-for-java-1-4. When I wrote it Java 1.4 was necessary for use on the BeagleBone, Plug, and Zotac single-board PCs but it's an easy conversion to 1.7+.
Are you using hardware flow control on your serial port? Is it possible that you're sending requests out when the local XBee has deasserted CTS (e.g., asking you to stop sending)? I assume you're running at 115200 bps, so the XBee serial port can keep up with the network data rate.
Can you turn on debugging information, or connect some port monitoring hardware/software to display the data going over the serial port to the local XBee?