I have a Debian machine (3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux) on which I have some audio devices connected. The devices that are stereo works well, but I have a problem with a mono headset. When I type the command
aplay -v -D plughw:2,0 ~/piano2.wav
the device waits up to 3-4 seconds before starting to output sound. If I retype the command in the following 5 seconds, the sound is played directly, but if I wait a bit more, I have to wait 3-4 seconds again before hearing anything.
Here is the output when I run the command above :
Playing WAVE '/home/console/piano2.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
Plug PCM: Route conversion PCM (sformat=S16_LE)
Transformation table:
0 <- 0*0.5 + 1*0.5
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 2
rate : 48000
exact rate : 48000 (48000/1)
msbits : 16
buffer_size : 24000
period_size : 6000
period_time : 125000
tstamp_mode : NONE
period_step : 1
avail_min : 6000
period_event : 0
start_threshold : 24000
stop_threshold : 24000
silence_threshold: 0
silence_size : 0
boundary : 6755399441055744000
Slave: Rate conversion PCM (16000, sformat=S16_LE)
Converter: libspeex (builtin)
Protocol version: 10002
Its setup is:
stream : PLAYBACK
access : MMAP_INTERLEAVED
format : S16_LE
subformat : STD
channels : 1
rate : 48000
exact rate : 48000 (48000/1)
msbits : 16
buffer_size : 24000
period_size : 6000
period_time : 125000
tstamp_mode : NONE
period_step : 1
avail_min : 6000
period_event : 0
start_threshold : 24000
stop_threshold : 24000
silence_threshold: 0
silence_size : 0
boundary : 6755399441055744000
Slave: Hardware PCM card 2 'Jabra PRO 9460' device 0 subdevice 0
Its setup is:
stream : PLAYBACK
access : MMAP_INTERLEAVED
format : S16_LE
subformat : STD
channels : 1
rate : 16000
exact rate : 16000 (16000/1)
msbits : 16
buffer_size : 8000
period_size : 2000
period_time : 125000
tstamp_mode : NONE
period_step : 1
avail_min : 2000
period_event : 0
start_threshold : 8000
stop_threshold : 8000
silence_threshold: 0
silence_size : 0
boundary : 9007199254740992000
appl_ptr : 0
hw_ptr : 0
And this is my .asoundrc file :
pcm.!default {
type plug
slave {
pcm "hw:0,0"
}
}
pcm.device1 {
type plug
slave {
pcm "hw:1,0"
}
}
pcm.device2 {
type plug
slave {
pcm "hw:2,0"
}
}
pcm.device3 {
type plug
slave {
pcm "hw:3,0"
}
}
ctl.!default {
type hw
card 0
}
ctl.device1 {
type hw
card 1
}
ctl.device2 {
type hw
card 2
}
ctl.device3 {
type hw
card 3
}
Does anybody have and idea why I get such a delay when my device wakes-up ?
Thanks
Related
I've set up a radio for local network, everything (Icecast2, BUTT (Broadcast Using This Tool)) is ready and working except one thing. BUTT intends to capture audio from input device, but that is not what I want, I want to stream desktop audio. I've created a loopback device using modprobe snd-aloop. I actually managed to route the audio from a specific program to that loopback device and I was able to hear it on the web player but the sound is stuttering, speeding up and getting back to normal its hard to describe. It's like decoder cannot catch up. All these are happening in less than a second.
Output from pactl list short sinks
1 alsa_output.pci-0000_00_1f.3.analog-stereo module-alsa-card.c s16le 2ch 48000Hz RUNNING
3 alsa_output.platform-snd_aloop.0.analog-stereo module-alsa-card.c s16le 2ch 44100Hz IDLE
11 alsa_output.pci-0000_01_00.1.hdmi-stereo module-alsa-card.c s16le 2ch 44100Hz IDLE
I have created ~/.asoundrc as most of the tutorial encouraged me to do so, and I believe this problem can be solved by this file but I am not familiar enough with alsa and its features. Sample rate of sound card is 48000 Hz but BUTT is forcing me to select 44100.
Contents of ~/.asoundrc
pcm.!default {
type asym
playback.pcm "LoopAndReal"
#capture.pcm "looprec"
capture.pcm "hw:0,0"
}
pcm.looprec {
type hw
card "Loopback"
device 1
subdevice 0
}
pcm.LoopAndReal {
type plug
slave.pcm mdev
route_policy "duplicate"
}
pcm.mdev {
type multi
slaves.a.pcm pcm.MixReale
slaves.a.channels 2
slaves.b.pcm pcm.MixLoopback
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.MixReale {
type dmix
ipc_key 1024
slave {
pcm "hw:0,0"
#rate 48000
rate 44100
periods 128
period_time 0
period_size 1024 # must be power of 2
buffer_size 8192
}
}
pcm.MixLoopback {
type dmix
ipc_key 1025
slave {
pcm "hw:Loopback,0,0"
#rate 48000
rate 44100
periods 128
period_time 0
period_size 1024 # must be power of 2
buffer_size 8192
}
}
Thanks in advance for any help.
I've managed to pipe my desktop audio to mic input using purely pulse audio and no alsa, thanks to this thread: https://unix.stackexchange.com/questions/82259/how-to-pipe-audio-output-to-mic-input
I am facing an issue where the period size has been set to 128, still sometimes the polling starts late.
For this configuration, where the period size is set to 128 and rate is 16 Khz, therefore polling should occur after each 128/16 = 8 ms, but in some cases the polling occurs a bit late which causes certain issues in the application. Since, polling is triggered internally by Alsa system modules which is dependent on the configuration, kindly suggest if we are going wrong somewhere with the configuration or any similar issue anyone might have experienced. Pasting the PCM dump of my Setup below:-
APCM_DUMP_DEVICE_DETALS :-
Hardware PCM card 0 'mt2712-d1v1' device 5 subdevice 0
Its setup is:
stream : CAPTURE
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 1
rate : 16000
exact rate : 16000 (16000/1)
msbits : 16
buffer_size : 512
period_size : 128
period_time : 8000
tstamp_mode : NONE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 128
period_event : 0
start_threshold : 128
stop_threshold : 512
silence_threshold: 0
silence_size : 0
boundary : 4611686018427387904
appl_ptr : 0
hw_ptr : 0
APCM_DUMP_DEVICE_DETALS :-
Hardware PCM card 0 'mt2712-d1v1' device 1 subdevice 0
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 1
rate : 16000
exact rate : 16000 (16000/1)
msbits : 16
buffer_size : 512
period_size : 128
period_time : 8000
tstamp_mode : NONE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 128
period_event : 0
start_threshold : 128
stop_threshold : 512
silence_threshold: 0
silence_size : 0
boundary : 4611686018427387904
appl_ptr : 0
hw_ptr : 0
APCM_DUMP_DEVICE_DETALS :-
Hardware PCM card 0 'mt2712-d1v1' device 12 subdevice 0
Its setup is:
stream : CAPTURE
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 1
rate : 16000
exact rate : 16000 (16000/1)
msbits : 16
buffer_size : 512
period_size : 128
period_time : 8000
tstamp_mode : NONE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 128
period_event : 0
start_threshold : 128
stop_threshold : 512
silence_threshold: 0
silence_size : 0
boundary : 4611686018427387904
appl_ptr : 0
hw_ptr : 0
APCM_DUMP_DEVICE_DETALS :-
Hardware PCM card 0 'mt2712-d1v1' device 11 subdevice 0
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 1
rate : 16000
exact rate : 16000 (16000/1)
msbits : 16
buffer_size : 512
period_size : 128
period_time : 8000
tstamp_mode : NONE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 128
period_event : 0
start_threshold : 128
stop_threshold : 512
silence_threshold: 0
silence_size : 0
boundary : 4611686018427387904
appl_ptr : 0
hw_ptr : 0
For the issue, we tried to analyze the kernel traces, after going through the kernel traces, we found out that we were reading the entire available data (snd_pcm_avail_update) for the capture device(rather than the period_size), due to which a flag in kernel was set to 0 since it had 0 bytes available due to which it was missing the interrupt to wake up the read thread(application) in time. Once we set the pcm_read to read only the required data, the behaviour was rectified
I am using the following code to get the audio sample of the 44100 sample rate from the iPhone 11.
iPhone 11 has a 48000 sample rate by default.
let audioEngine = AVAudioEngine()
let inputNode = audioEngine.inputNode
let main = audioEngine.mainMixerNode
let inputFormat = inputNode.inputFormat(forBus: 0)
let outputFormat = AVAudioFormat(commonFormat: AVAudioCommonFormat.pcmFormatInt16, sampleRate: 44100, channels: 1, interleaved: true)
audioEngine.attach(downMixer)
audioEngine.connect(inputNode, to: downMixer, format: inputFormat)
audioEngine.connect(downMixer, to: main, format: outputFormat)
downMixer.installTap(onBus: 0, bufferSize: 2048, format: outputFormat) { (buffer, time) -> Void in
print(buffer)
}
I am getting null audio data.
You can use Audio Converter Services for converting 48 K Hz to 44.1 K Hz sampling frequency. As all the sampling frequency is not supported by the iOS/iphone platform.
https://developer.apple.com/documentation/audiotoolbox/audio_converter_services
I'm struggling to understand what I'm doing wrong in my audio playback routine.
I've a thread that takes buffers from other threads and plays them the same way this alsa example program does: https://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm_8c-example.html
I'm referring to the write_loop() function. This is the device configuration setup up of the pcm.c example program (output of snd_pcm_dump()):
ALSA <-> PulseAudio PCM I/O Plugin
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 1
rate : 44100
exact rate : 44100 (44100/1)
msbits : 16
buffer_size : 22050
period_size : 4410
period_time : 100000
tstamp_mode : NONE
tstamp_type : GETTIMEOFDAY
period_step : 1
avail_min : 4410
period_event : 0
start_threshold : 22050
stop_threshold : 22050
silence_threshold: 0
silence_size : 0
boundary : 6206523236469964800
What I see placing some printf() around snd_pcm_writei() is that it gets executed 5 times straight and every next loop snd_pcm_writei() takes 100ms to complete. This is exactly what I was expecting to see.
This is device setup of my program:
ALSA <-> PulseAudio PCM I/O Plugin
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : FLOAT_LE
subformat : STD
channels : 1
rate : 44100
exact rate : 44100 (44100/1)
msbits : 32
buffer_size : 13230
period_size : 4410
period_time : 100000
tstamp_mode : NONE
tstamp_type : GETTIMEOFDAY
period_step : 1
avail_min : 4410
period_event : 0
start_threshold : 4410
stop_threshold : 13230
silence_threshold: 0
silence_size : 0
boundary : 7447827883763957760
What happens is snd_pcm_writei() runs 5 times (and this is ok) but after that every new loop it returns immediately with -EAGAIN. Retrying continuously for 100ms (100% cpu usage) to play the same buffer eventually it gets played, snd_pcm_writei() returns a positive number and for next audio buffer I get immediately -EAGAIN, for 100ms; and so on. The audio playback, however, is fine.
What I don't understand is why it doesn't wait 100ms to play the new buffer instead of returning immediately -EAGAIN (cannot find anything in ALSA docs about snd_pcm_writei() returning -EAGAIN).
Thanks in advance for any help!
A PCM device can be in blocking mode (waiting) or in non-blocking mode (returning -EAGAIN).
This mode can be set with a flag when calling snd_pcm_open(), or with snd_pcm_nonblock().
Goal
Measure the CPU temperature of my Linux Box.
Work done till now
I have installed lm-sensors to detect the temperature and below is the output of the command sensor:
root#XXXX-XX :# sensors
acpitz-virtual-0
Adapter: Virtual device
temp1: +66.0°C (crit = +255.0°C)
k10temp-pci-00c3
Adapter: PCI adapter
temp1: +65.4°C (high = +70.0°C)
(crit = +100.0°C, hyst = +99.0°C)
radeon-pci-0008
Adapter: PCI adapter
temp1: +64.0°C (crit = +120.0°C, hyst = +90.0°C)
radeon-pci-0100
Adapter: PCI adapter
temp1: N/A (crit = +120.0°C, hyst = +90.0°C)
The output of the cat /proc/cpuinfo is:
processor : 0
vendor_id : AuthenticAMD
cpu family : 21
model : 16
model name : AMD A8-4500M APU with Radeon(tm) HD Graphics
stepping : 1
microcode : 0x6001116
cpu MHz : 1400.000
cache size : 2048 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 16
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
.
.
.
processor : 1
vendor_id : AuthenticAMD
cpu family : 21
model : 16
model name : AMD A8-4500M APU with Radeon(tm) HD Graphics
stepping : 1
microcode : 0x6001116
cpu MHz : 1400.000
cache size : 2048 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 17
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
processor : 2
vendor_id : AuthenticAMD
cpu family : 21
model : 16
model name : AMD A8-4500M APU with Radeon(tm) HD Graphics
stepping : 1
microcode : 0x6001116
cpu MHz : 1400.000
cache size : 2048 KB
physical id : 0
siblings : 4
core id : 2
cpu cores : 2
apicid : 18
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
processor : 3
vendor_id : AuthenticAMD
cpu family : 21
model : 16
model name : AMD A8-4500M APU with Radeon(tm) HD Graphics
stepping : 1
microcode : 0x6001116
cpu MHz : 1400.000
cache size : 2048 KB
physical id : 0
siblings : 4
core id : 3
cpu cores : 2
apicid : 19
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
Question
Out of the above readings from command sensor and cat /proc/cpuinfo, I am not sure which is exactly my cpu temperature in the output of sensors and what is the one to one relation between the output of both the commands (ie: which field (ie:output of sensor) matches with the field of cat /proc/cpuinfo).
Your cpu temperature is shown by the k10 sensor, but beware it is assumed to be inaccurate.
https://www.kernel.org/doc/Documentation/hwmon/k10temp