On a basic embedded systems speaker with a single line of output, wiggling the output as 0 or 1 in a for given periods produces sound.
I'd like to do something similar on a modern Linux desktop. A brief look-see of Portaudio, OpenAL, and ALSA suggests to me that most people do things at a considerable higher level. That's ok, but not what I'm looking for.
(I've never worked with sounds on Linux before, so if a tutorial exists, I'd love to see it).
Actually, it... kinda is. While you can generate the waveform yourself, you still need to use an API to queue it and send it to the audio hardware; there no longer even exists a sane way to twiddle the audio line directly. Plus you get cross-platform compatibility for free.
[...] embedded systems speaker with a single line of output, wiggling the output as 0 or 1 in a for given periods produces sound.
Sounds a lot like the old PC speaker. You might still find code for it in the Linux kernel.
I'd like to do something similar on a modern Linux desktop.
Then you need AFAIK a driver for ALSA. There you can find infos on how to write an ALSA driver. Use PWM to produce the sound.
Since there are many different sound cards and audio interfaces produced by different companies, there is no uniform way to have a low level access to them. With most sound I/O APIs what you need to do is to generate the PCM data and send that to the driver. That's pretty much the lowest level you can go.
But PCM data is very similar to the 0-1 approach you describe. It's just that you have the in-between options too. 0-1 is 1-bit audio. 8-, 16-, 24-bit audio is what you'll find on a modern sound card. There are also 32- and 64-bit float formats. But they're still similar.
Related
I need to do some NON-STANDARD signal processing operations with an RFID-reader, so I'd like to know if it is possible to extract antenna's individual analog (actually digital samples right after ADC) input signal samples with Motorola FX7500 (if you know how this works on FX7400 or FX9500, please do tell, could be helpful). Samples would be processed in a JAVA-based host computer program.
What I've already tried:
Investigating Motorola's own RFID3 API's possibilities, it doesn't go deep enough to actually get in touch with input analog signal samples.
Using LLRP to its full extent, it doesn't allow analog signal sample access either. RFsurvey-functionality would have been helpful to some extent, but FX7500 doesn't support it either.
Accessing RFID-reader's linux terminal, trying to find the driver function(s), that could listen the input sample stream. If current input sample(s) could be extracted from the input stream, I could (in theory) make a script, that would save a few of those sample values in a txt-file in the host computer during a tag inventory round. My linux skills are kinda bad, hence I ask this question.
The only realistic way to solution seems to be via linux terminal, so if you folks have any ideas about that (where to look and what to do), please advise!
Contents of reader:
rfidadm#FX7500abcdef:/$ ls -1
apps
bin
dev
etc
home
include
lib
linuxrc
media
mnt
platform
proc
readerconfig
run
sbin
sys
tmp
usr
var
I cannot completely rule that out, but it's highly unlikely you can get the raw signal digitized; the devices you're looking at aren't really software defined radio devices, typically.
"speaking" RFID physically is a bit different from "usual" wireless communication: The reader doesn't only observe the energy transmitted from the tag, but more importantly the fluctuations of energy extracted from the near field of the reader's antenna coil. Hence, you don't actually have a baseband of RF bandpass signal, but hardware-specific modulations of transmitted (and inversely, antenna-reflected) energy. Demodulation is hence usually done in specialized hardware.
However, do not fret: It's totally possible to build a software defined RFID reader. There have been several approaches to that, but personally, I trust these based on Ettus USRPs and/or GNU Radio best. Look through the results IEEExplore gives you, eg. this search.
Most probably this is not possible with the Motorola readers. What you can do, is use one of the RFID chipsets available on the market: either the AMS RFID IC's, or the Impinj RFID IC's. As far as I know, both IC's support retrieving the digital samples that are received. They also have a development kit to test-drive the IC's.
I have a situation where I have a video capture of HD content via HDMI with audio from a sound board that goes through a impedance drop into a microphone input of a camcorder. That same signal is split at line level to a 'line in' jack on the same computer that is capturing the HDMI. Alternatively I can capture the audio via USB from the soundboard which is probably the best plan, but carries with it the same issue.
The point is that the line in or usb capture will be much higher quality than the one on HDMI because the line out -> impedance change -> mic in path generates inferior quality in that simply brushing the mic jack on the camera while trying to change the zoom (close proximity) can cause noise on the recording.
So I can do this today:
Take the good sound and the camera captured sound and load each into
audacity and pretty quickly use the timeshift toot to perfectly fit
the good audio to the questionable audio from the HDMI capture and
cut the good audio to the exact size of the video. Then I can use
ffmpeg or other video editing software to replace the questionable
audio with the better audio.
But while somewhat quick and easy, it always carries with it a bit of human error and time. I'd like to automate this if possible as this process is repeated at least weekly throughout the year.
Does anyone have a suggestion if any of these ideas have merit or could suggest another approach?
I suspect but have yet to confirm that the system timestamp of the start time may be recorded in both audio captured with something like Audacity, or the USB capture tool from the sound board as well as the HDMI mpeg-2 video. I tried ffprobe on a couple audacity captured .wav files but didn't see anything in the results about such a time code, but perhaps other audio formats or other probing tools may include this info. Can anyone advise if this is common with any particular capture tools or file formats?
if so, I think I could get best results by extracting this information and then using simple adelay and atrim filters in ffmpeg to sync reliably directly from the two sources in one ffmpeg call. This is all theoretical for me right now-- I've never tried either of these filters yet-- just trying to optimize against blind alleys by asking for advice up front.
If such timestamps are not embedded, possibly I can use the file system timestamp for the same idea expressed in 1a, but I suspect the file open of the two capture tools may have different inherant delays. Possibly these delays will be found to be nearly constant and the approach can work with a built-in constant anticipation delay but sounds messy and less reliable than idea 1. Still, I'd take it, if it turns out reasonably reliable
Are there any ffmpeg or general digital audio experts out there that know of particular filters that can be employed on the actual data to look for similarities like normalizing the peak amplitudes or normalizing the amplification of the two to some RMS value and then stepping through a short 10 second snippet of audio, moving one time stream .01s left against the other repeatedly and subtracting the two and looking for a minimum? Sounds like it could take a while, but if it could do this in less than a minute and be reliable, I suspect it could work. But I have only rudimentary knowledge of audio streams and perhaps what I suggest is just not plausible-- but since each stream starts with the same source I think there should be a chance. I am just way out of my depth as to how to go down this road, so if someone out there knows such magic or can throw me some names of filters and example calls, I can explore if I can make it work.
any hardware level suggestions to take a line level output down to a mic level input and not have the problems I am seeing using a simple in-line impedance drop module, so that I can simply rely on the audio from the HDMI?
Thanks in advance for any pointers or suggestinons!
I'm trying to make a video tutorial, so i decided to record the speeches using a TTS online service.
I use Audacity to capture the sound, and the sound was clear !
After dinning, i wanted to finish the last speeches, but the sound wasn't the same anymore, there is a background noise(parasite) which is disturbing, i removed it with Audacity, but despite this, the voice isn't the same ...
You can see here the difference between the soundtrack of the same speech before and after the occurrence of the problem.
The codec used by the stereo mix peripheral is "IDT High Definition Codec".
Thank you.
Perhaps some cable or plug got loose? Do check for this!
If you are using really cheap gear (built-in soundcard and the likes) it might very well also be a problem of electrical interference, anything from ...
Switching on some device emitting a electro magnetic field (e.g. another monitor close by)
Repositioning electrical devices on your desk
Changes in CPU load on your computer (yes i'm serious!)
... could very well cause some kinds of noises with low-fi sound hardware.
Generally, if you need help on audio sounding wrong make sure that you provide a way to LISTEN to the files, not just a visual representation.
Also in your posted waveform graphics i can see that the latter signal is more compressed, which may point to some kind of automated levelling going on somewhere in the audio chain.
I've been looking online for solutions on how to generate a simple beep with an DE2 Altera board using VHDL but I can not seem to find anything.
I've seen some things that are talking about Audio Codec but I haven't been able to get a firm grasp of what I would need to do with it.
Thanks a lot!
-Will
The "audio codec" is a separate chip (a Wolfson WM8731 in your case) which can turn information on digital form into analog information to be amplified/played through a standard sound system with amplifier/speaker/etc.
You'll need to find out how to interface to the audio codec chip from the FPGA (google a datasheet for the chip), and then send it the necessary information to generate you beep. Depending on how advanced the audio chip is, this task can vary rather much in complexity. As it's an educational board, you might be able to find people who've already done something similar, and then build on their experience.
If all you need is a simple beep though, you might also be able to create a simple circuit with a piezo-buzzer or similar yourself - that can be controlled without having to use an audio codec...
I have a rather different question. So I'm using Matlab on a Linux Gentoo machine. I got a few Asus Xonar STX soundcards, and I'm trying to use them as sensitive audio frequency analyzer using the PlayRec non blocking audio IO package.
Now I know that Matlab will say if you try to use the audiorecorder function, and specify 24 bits in linux, it will tell you that 24bit is only supported in Windows. However the ALSA literature does not imply that this is a limitation of the operating system or of ALSA itself, and as a matter of fact Alsa seems to allow you to specify a 24 bit PCM device. And PlayRec uses PortAudio, which then uses Alsa on Linux systems.
Now this is all well and good, and Playrec doesn't seem to have a means of specifying the bit depth, just the sample rate. I have run many tests and know what the transfer function of my soundcard is (floating point return value to input Voltage conversion ratio), and I know my peak voltage is 3V, and my noise is around 100uV. This gives me 20*log10(3/100e-6) = 91dB. Which is closer to what I expect to see from 16 bits and not from 24.
My real question is this: Is there some way of verifying that I am in fact getting 24 bits in my captured signal?
And if I am not, is there some inherent limitation of ALSA or Matlab which is restricting me to only 16-bit data from sound capture devices, even when using 3rd party program to gather that data.
If you observe the data that playrec is putting out through playrec('getRec', ...), you'll see that it always is single-precision floating point (tested on Windows, MATLAB R2013b, most current Playrec). (you can verify it yourself after recording a single page with Playrec and looking in the workspace window of the IDE or by running whos('<variable_name_of_page>') at the command line.
If you look at Line 50 of pa_dll_playrec.h, you'll see that single-precision is chosen by definition:
/* Format to be used for samples with PortAudio = 32bit */
typedef float SAMPLE;
Unfortunately, this does not completely answer the question of exact sample precision, because the PortAudio lib converts samples from the APIs varying in format into the defined one. So if you want to know, what precision you're actually getting, I'd suggest a very pragmatic solution: looking at the mantissa of the 32-bit floating sample values. A simple fprintf('%+.32f\n', data) should suffice to find out how many decimal places are actually used.
Edit: I just realized I got it wrong. But here's the trick: Record audio off of an empty channel of your audio device. Plot the recorded data and zoom into the noise floor. If you're just getting plain zeros, the device is probably not activated properly (or has a too good signal/noise ratio). Try an external interface and/or turn up the gain a little bit). Depending on the actual bit resolution of the recorded data, you'll see quantization steps in the samples. Depending on the bit-depth originally used by the quantizer, those steps are bigger or smaller. Below you'll see the comparison between 16-bit (left) and 24-bit (right) of to seperately recorded blocks, from the same audio device, only that I used PortAudio's WASAPI API (on Windows, obviously) on the left and ASIO on the right:
The difference is quite obvious: at these very low levels, 16-bit only allows three values, while 24-bit has much finer stepping. So this should be a sufficient answer to your question on how to determine the real bitdepth and if your signal is recorded at 24-bit. If there are sample steps smaller than 2^-15, the odds are pretty good.
Looking in to this topic made me realize that it very much depends on the API of the currently chosen recording device, which bit-depth the quantization actually happens at. ASIO seems to always use 24-bit, while for example WASAPI falls back to 16-bit.
If you can store that signal as a wav file, run a file command on the wav from the command line in linux. Something like:
file x.wav will give you sampling rate and bits that the file was encoded at. The output is usually something like: 16 bit, 16000Hz etc.