When I tried to play a float format wave with 24k sample rate via alsa dmix plugin, I got an error message as below:
aplay /dev/urandom -r24000 -ffloat_le -v -Dplug:dmix
Playing raw data '/dev/urandom' : Float 32 bit Little Endian, Rate 24000 Hz, Mono
aplay: set_params:1145: Unable to install hw params:
ACCESS: RW_INTERLEAVED
FORMAT: FLOAT_LE
SUBFORMAT: STD
SAMPLE_BITS: 32
FRAME_BITS: 32
CHANNELS: 1
RATE: 24000
PERIOD_TIME: (21333 21334)
PERIOD_SIZE: NONE
PERIOD_BYTES: (2044 2048)
PERIODS: NONE
BUFFER_TIME: (341333 341334)
BUFFER_SIZE: 8192
BUFFER_BYTES: 32768
TICK_TIME: 0
There are some relationships with "float", "24k" and dmix. Is it a known issue of alsa?
Would you please help me about it? Thank you.
Related
I'm using eclipse software and when I want to upload my code to the MCU(atmega32) with a clock of 16MHZ the avrdude takes longer than it should, however the program runs as it should but the only problem is the avrdude uploading time. the following example shows that it took more than 1.5 minutes to upload the program, so how can I decrease this time?
Launching D:\Programs\03- IMT SDK\IMT_SDK_Win_64\WinAVR\bin\avrdude -pm32 -cusbasp -P230400 -b230400 -Uflash:w:1542.hex:a
Output:
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1e9502
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "1542.hex"
avrdude: input file 1542.hex auto detected as Intel Hex
avrdude: writing flash (7518 bytes):
Writing | ################################################## | 100% 62.72s
avrdude: 7518 bytes of flash written
avrdude: verifying flash memory against 1542.hex:
avrdude: load data flash data from input file 1542.hex:
avrdude: input file 1542.hex auto detected as Intel Hex
avrdude: input file 1542.hex contains 7518 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 34.79s
avrdude: verifying ...
avrdude: 7518 bytes of flash verified
avrdude done. Thank you.
avrdude finished
Calculating the value of 7518 bytes / 62.72 s gives an upload speed of 120 bytes/sec, while USBasp could provide a programming speed of up to 5 kBytes/sec. The upload speed could certainly be increased.
First of all, make sure that the jumper connected to PC2 port of the USBasp is removed. It is designed to activate the slow operation option to support targets with low clock speed (< 1,5 MHz).
Secondly, you do not have to specify the upload speed manually, so the command could be simplified:
avrdude –c usbasp –p m32 –U flash:w:1542.hex
I'm using the alsa-lib in my embeded linux. The next is my .asoundrc.
pcm.rate16k {
type plug
slave {
pcm "hw:0,0"
rate 16000
}
}
It works well when I play a mono audio file(rate is 48000Hz and format is S16_LE) using commands aplay -D rate16k -c 1 -r 48000 -f S16_LE test_48k.raw.
What I am confused is where the resample process implemented. I read the alsa-project introduction and read source code of alsa-lib and analyze the snd_pcm_open API.
snd_pcm_open ==> _snd_pcm_plug_open ==> _snd_pcm_hw_open ==> snd_pcm_hw_open ==> snd_pcm_hw_open_fd and here return the slave pcm pointer. Then aplay then calls snd_pcm_writei to write audio data and eventually calls snd_pcm_mmap_writei.
I try to analyze snd_pcm_mmap_writei but the alsa-lib is so complex that I still have no idea about how the rate converted. Please help or try to give some ideas how to analyze this process.
I am trying to create an application that will stream audio with Darkice as well as provide a LED VU meter indication of the audio stream.
I have created a virtual card with . This card is recognized by alsamixer, aplay, and arecord but I can not transfer the line-in signal from the usb card (hw:0,0) to the dummy card (hw:2,0).
I have tried several .asoundrc scripts that I found both in your Q&A as well as Google using alsa dmix, dsnoop, and multi but nothing has worked so far.
I am presently using one python program (LED_VU.py) that autostarts in one terminal, and the second python program containing Darkice (streamer.diDual.py) in a second terminal. The configuration portion of the LED program is:
### LED VU Meter on RPI ###
#!/usr/bin/env python
import alsaaudio as AA
import audioop
from time import sleep
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BOARD)
GPIO.setwarnings(False)
#Define physical header pin numbers for 10 LEDs
RPiPins=[11,12,13,15,16,18,22,7,3,5]
#set all pins as output
for pin in RPiPins:
GPIO.setup(pin, GPIO.OUT)
#Set up audio
card = 'hw:0,0'
The configuation portion of darkiceDual.cfg is:
# Darkice Configuration File - Generated by Streamer
[general]
duration = 0 # duration of encoding, in seconds. 0 means forever
bufferSecs = 5 # size of internal slip buffer in seconds
reconnect = yes # reconnect to server if disconnected
[input]
device = hw:2,0 # alsa usb soundcard device for audio input
sampleRate = 44100 # sample rate in Hz
bitsPerSample = 16 # bits per sample
channel = 2 # channels. 1 = mono, 2 = stereo
My .asoundrc file is:
pcm.!default {
type plug
slave.pcm "mdev"
route_policy "duplicate"
}
pcm.mdev {
type multi
slaves.a.pcm "hw:0,0"
slaves.a.channels 2
slaves.b.pcm "dmixer"
slaves.b.channels 2
bindings.0.slave a
bindings.0.channel 0
bindings.1.slave a
bindings.1.channel 1
bindings.2.slave b
bindings.2.channel 0
bindings.3.slave b
bindings.3.channel 1
}
pcm.dmixer {
type dmix
ipc_key 1024
slave {
pcm "hw:2,0"
period_time 0
period_size 1024
buffer_size 4096
rate 44100
channels 2
format S16_LE
}
}
What am I doing wrong?
The streamer will have no audio if I use hw:2,0 and have the 'Can not connect' error if I use hw:0,0 (LED_VU.py is using this). If I change the card setting of the LED program to hw:2,0 the LEDs will lockup with all of them lit.
Any help is appreciated!
Thank you for the help. The two programs both use the usb line-in as expected.
I am not able to use alsamixer or amixer now. Pulseaudio is causing the problem now. If it is installed, the LED_VU.py program will not run. When it is uninstalled, the python programs will run but not alsamixer.
Apparently, you want to run the VU meter and DarkIce from the same audio data, i.e., you need to allow two programs to share one recording device.
This can be done with the dsnoop plugin. Which is enabled by default for USB devices.
Tell both programs to record from the device default. If that was redefined, try dsnoop:0 instead.
I have been trying to mod a default firmware of a Digital Video Recorder just because of its splash screen logo, which is incredibly bright and almost blinds me everytime I turn it on at night.
I have tried to use the Firmware Mod Kit to extract the firmware from the binary file. Instead of coming across a squash or cram filesystem, I ended up with some zip compressed files. Here's some output:
Scan Time: 2015-08-17 23:28:44
Signatures: 193
Target File: /home/king/fmk/myfirmware.bin
MD5 Checksum: [omitted]
DECIMAL HEX DESCRIPTION
-------------------------------------------------------------------------------------------------------
0 0x0 Zip archive data, at least v2.0 to extract, compressed size: 2118527, uncompressed size: 2154560, name: "custom-x.cramfs.img"
2118597 0x2053C5 Zip archive data, at least v2.0 to extract, compressed size: 2928495, uncompressed size: 2932800, name: "user-x.cramfs.img"
5047160 0x4D0378 Zip archive data, at least v2.0 to extract, compressed size: 2424987, uncompressed size: 2445376, name: "romfs-x.cramfs.img"
7472216 0x720458 Zip archive data, at least v2.0 to extract, compressed size: 18725, uncompressed size: 20544, name: "logo-x.cramfs.img"
7491009 0x724DC1 Zip archive data, at least v2.0 to extract, compressed size: 141, uncompressed size: 354, name: "InstallDesc"
7491611 0x72501B End of Zip archive
Extracting 0 bytes of zip header image at offset 0
ERROR: No supported file system found! Aborting...
However, If I unzip the binary file, I can get FMK to extract the only file I'd really like to change: logo-x.cramfs.img:
king#castle:~/fmk$ ./extract-firmware.sh logo-x.cramfs.img:
Firmware Mod Kit (extract) 0.99, (c)2011-2013 Craig Heffner, Jeremy Collake
Preparing tools ...
Scanning firmware...
Scan Time: 2015-08-18 00:19:50
Signatures: 193
Target File: /home/king/fmk/logo-x.cramfs.img
MD5 Checksum: [omitted]
DECIMAL HEX DESCRIPTION
-------------------------------------------------------------------------------------------------------
0 0x0 uImage header, header size: 64 bytes, header CRC: 0x94AD77F7, created: Sun May 26 23:46:43 2013, image size: 20480 bytes, Data Address: 0x10770000, Entry Point: 0x10780000, data CRC: 0x8EDB113D, OS: Linux, CPU: ARM, image type: Standalone Program, compression type: gzip, image name: "linux"
64 0x40 CramFS filesystem, little endian size 20480 version #2 sorted_dirs CRC 0xbda508c, edition 0, 5 blocks, 2 files
Extracting 64 bytes of uimage header image at offset 0
Extracting cramfs file system at offset 64
Extracting CramFS file system...
Now I'm not sure how to proceed. build-firmware script won't mount it back to an .img file, and even if it does, I can't repack the initial binary as well because I had to manually extract it instead of doing via extract-firmware script.
Thoughts? I don't really want to brick my dvr, almost giving this up. Any helpful comments are largely appreciated.
In fmk it's not possible.
It's more complicated process since you need to generate headers ... all steps here:
http://sysmagazine.com/posts/213411/
I'm trying to read a raw MIDI file.
My question is, if I have, for instance, e MIDI with 36 seconds length of my WMplayer, how can I get the same time by performing calculation with MIDI info.
In this file, I have:
ticks per 1/4 : 192
delta time total : 13822
no tempo info so, (I guess) : 500 micro s per 1/4
Thanks
Already figured it out!
to get you time (milliseconds) per tick, 500/192 ~ 2.6
to get the time of the track simply, 2.6(time per tick) * (total of delta times) = 35.9 ~ 36''
Thanks