I'm trying to use libusb-1.0 to pull audio samples through an isochronous transfer on a USB recording device. I imagined that for an isochronous transfer this would be easy, i.e. no control transmissions needed, just connect and read from the designated interface, but what I'm reading appears to be device information. (See the hexdump below. See source code file on pastebin.)
So my question is how do I stream audio from a USB device? (I've read USB In a Nutshell. I've confirmed that the interface, alternate setting, and endpoint I'm using are for Isochronous OUT by using lsusb -v. See pastebin for full device information.) I don't think that I need to (or can) send any control signals to alter the configuration of clocks/channels/interrupts because the control interface has no endpoints (as you can see in the foregoing link).
Here's the "character" portion of the top of a hexdump -C from the packets I captured with libusb-1.0. (See the whole hexdump at pastebin):
................................14.0/usb2/2-3.2-0:1.0...........
`.......x.......................1d.0/usb1/1-1/1-1:1.0.1.5:1.0...
`.......x.......`.......0.......................b2/2-0:1.0......
0.......1........!..............................14.0/usb2/2-0:1.
0...............................#.............DEVTYPE.usb_inte
rface.DRIVER.hub.PRODUCT.1d6b/2/404.TYPE.9/0/0.INTERFACE.9/0/0.M
ODALIAS.usb:v1D6Bp0002d0404dc09dsc00dp00ic09isc00ip00in00.......
................................................................
...............................................DEVTYPE.usb_inte
rface.DRIVER.hub.PRODUCT.1d6b/3/404.TYPE.9/0/3.INTERFACE.9/0/0.M
ODALIAS.usb:v1D6Bp0003d0404dc09dsc00dp03ic09isc00ip00in00.......
................*................................14.0/usb2/2-3.2-
0:1.0...........`.......x.......................1d.0/usb1/1-1/1-
1:1.0.1.5:1.0...`.......x.......`.......0.......................
b2/2-0:1.0......0.......1........!..............................
14.0/usb2/2-0:1.0...............................* # ....... ......
Related
During the installation, we are supposed to check the sound card by pressing ‘arecord -L’ to obtain a certain output like shown below,
pi#raspberrypi:~ $ arecord -L
null
Discard all samples (playback) or generate zero samples (capture)
jack
JACK Audio Connection Kit
pulse
PulseAudio Sound Server
default
playback
ac108
sysdefault:CARD=seeed4micvoicec
seeed-4mic-voicecard,
Default Audio Device
dmix:CARD=seeed4micvoicec,DEV=0
seeed-4mic-voicecard,
Direct sample mixing device
dsnoop:CARD=seeed4micvoicec,DEV=0
seeed-4mic-voicecard,
Direct sample snooping device
hw:CARD=seeed4micvoicec,DEV=0
seeed-4mic-voicecard,
Direct hardware device without any conversions
plughw:CARD=seeed4micvoicec,DEV=0
seeed-4mic-voicecard,
Hardware device with all software conversions
usbstream:CARD=seeed4micvoicec
seeed-4mic-voicecard
USB Stream Output
usbstream:CARD=ALSA
bcm2835 ALSA
USB Stream Output
However, the output that I have received is as shown below,
Screenshot of Output
It basically shows that I don’t have the ALSA soundcard, and I cant move on to the sound localization process. Please show how can I move forward, thanks!
I'm trying to send files over a half-duplex interface (RS-485) between a box PC running debian (4.19) and a SBC with an im6xDL.
Thanks to this community I can successfully transfer simple data between the units using picocom or by echoing/reading.
The box PC supports half-duplex RS-485 natively and has automatic RTS functions so that you can read/send data without any issue. The SBC on the other hand needs to be toggled to change into RX or TX mode.
This turned out to be a problem when I tried to send files from the box PC to the SBC.
On the box PC:
picocom /dev/ttyUSB0 -b 9600 -fn
C-a,C-S
***file: /home/user/test.txt
Transfer incomplete
*** exit status: 128
On the SBC
picocom /dev/ttymxc2 -b 9600 -fn -et
C-a,C-r
Terminal ready
�000000
As you can see something is terribly wrong, it is like it cannot interpret the bits when a file is being transferred.
My questions:
Is it possible to send files from the command line in half-duplex systems? (The SBC needs to be in RX mode the entire time).
Is there another way to achieve this that is more intuitive?
As always, thanks for the help and support :)
/W
See here:
Pymodbus - Read input register of Energy meter over rs485 on uart of raspberry pi3
The solution I presented there using pylibmodbus should work for any hardware with UART and one or two GPIO lines accessible from user space in Linux.
If, on the other hand, what you want to do is use something like picocom or minicom then you can take a look at the hardware-only solution using a 555 timer.
Of course, if prototyping circuits is not for you, you can always buy a USB to RS485 with half-duplex support. You have many available but those based on the MAX13487 IC seem to work very well.
EDIT: The solution using the 555 timer is not in the post I linked above but here together with some more background material on half-duplex RS485 links: RS485: Inappropriate ioctl for device
I want to write dummy ALSA compliant driver as a loadable kernel module. When accessing it by aplay/arecord throught the ALSA-lib, let's say, it must behave as normal 7.1 channel audio device providing all the basic controls at least - sampling rates, number of channels, format, etc...
Underneath it will just get every channel from the audio stream and will send it through the network as UDP packet stream.
It must be capable to be loaded multiple times and ultimately it would expose as many as want audio devices under /dev. In that way we will have multiple virtual sound cards in the system.
What should be the minimal structure of such a kernel module?
Can you give me an example skeleton (at least the interfaces) to be 100% ALSA compliant?
ALSA driver examples are so poor...
I think I've just found what I need.
There are no better ALSA interface examples than "dummy" and "aloop" templates under sound/drivers directory in the kernel tree:
https://alsa-project.org/main/index.php/Matrix:Module-dummy
https://www.alsa-project.org/main/index.php/Matrix:Module-aloop
I'll need to implement the network part only.
EDIT:
Adding yet another project for a very simple but essential virtual ALSA driver:
https://alsa-project.org/main/index.php/Minivosc
EDIT 2020_09_25:
Yet another great ALSA example:
https://www.openpixelsystems.org/posts/2020-06-27-alsa-driver/
install alsa-base alsa-util
modprobe snd-dummy
use alsamixer or use mocp(need install moc) to conifg add dummy-audio success
I use Arduino for comunication between sensors and my C# application using a serial port. Is there any possibility to access digital components directly such as Force Sensitive Resistor - Square, from a USB port?
Do I have to write a driver for that?
I drew a semi-schematic diagram to exemplify:
There isn't a way to directly read an analog sensor over USB since it's a digital bus. You need some sort of processing to convert the analog signal to digital and communicate over the bus properly.
In order to sample information from any sensor, you will need an intermediary. The Arduino uses an FTDI chip to convert UART (Serial) to USB. When you read data over this connection, you are reading it over the Serial over USB interface. My recommendation is to stick with using the Arduino or other micro controller.
If you are really bent on reading it Directly over USB (instead of through the Serial over USB converter) you would have to implement some sort of protocol in a device that supports USB such as the Stellaris Launchpad or an Atmega32U4 AKA Arduino Lenardo. You would also have to write a driver to describe how to communicate with this USB device. Unless you were able to implement it as an already known device such as a keyboard or serial port (Yep, we went full circle there).
In short, there's no already made chip that converts Analog (or Digital) values from a sensor into something any OS would natively understand. Since USB is a protocol much like IP, you're not going to be able to use discreet devices. You're going to have to use a micro-controller with a USB stack.
Again, my advice would be to pass the sensor values over USB through the existing Serial (over USB) port. This is pretty straight forward and easily reproducible without an entire Arduino.
From the looks of the force-sensitive resistor, this is an analog component; the resistance and capacitance changes with the force applied to the sensor. If you check out the FSR installation guide document there are suggested electrical interfaces starting on page 16.
I would recommend the first circuit, connect Vout to an analog input on the Arduino. From there you will need to convert from ADC counts to voltages and then use a lookup table function in the Arduino to convert from voltage to force according to Figure 9. At this point you have a variable containing the force applied to the sensor. From here you can transmit the value over the USB serial bus just like any other value. Your C# application then needs to read the serial data, and parse out the value.
I have a capture card that captures SDI video with embedded audio. I have source code for a Linux driver, which I am trying to enhance to add video4linux2 support. My changes are based on the vivi example.
The problem I've come up against is that all the example I can find deal with only video or only audio. Even on the client side, everything seems to assume v4l is just video, like ffmpeg's libavdevice.
Do I need to have my driver create two separate devices, a v4l2 device and an alsa device? It seems like this makes the job of keeping audio and video in sync much more difficult.
I would prefer some way for each buffer passed between the driver and the app (through v4l2's mmap interface) contain a frame, plus some audio that matches up (with respect to time) with that frame.
Or perhaps have each buffer contain a flag indicating if it is a video frame, or a chunk of audio. Then the time stamps on the buffers could be used to sync things up.
But I don't see a way to do this with the V4L2 API spec, nor do I see any examples of v4l2-enabled apps (gstreamer, ffmpeg, transcode, etc) reading both audio and video from a single device.
Generally, the audio capture part of a device shows up as a separate device. It's usually a different physical device (posibly sharing a card), which makes sense. I'm not sure how much help that is, but it's how all of the software I'm familiar with works...
There are some spare or reserved fields in the v4l2 buffers that can be used to pass audio or other data from the driver to the calling application via pointers to mmaped buffers.
I modified the BT8x8 driver to use this approach to pass data from an A/D card synchronized to the video on Ubuntu 6.06.
It worked OK, but the effort of maintaining my modified driver caused me to abandon this approach.
If you are still interested I could dig out the details.
IF you want your driver to play with gstreamer etc. a separate audio device generally is what is expected.
Most of the cheap v4l2 capture card's audio is only an analog pass through with a volume control requiring a jumper to capture the audio via the sound card's line input.