I installed portaudio on Ubuntu 14.04 and compiled a test program as follows:
gcc -o Test3c Test3c.c ../libportaudio.a -lrt -lasound -ljack -lpthread -lm
which had no errors. (Test3c.c is the same as the included pa_devs.c, which can be found here.) But when I run it,
./Test3c
I get this:
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
bt_audio_service_open: connect() failed: Connection refused (111)
bt_audio_service_open: connect() failed: Connection refused (111)
bt_audio_service_open: connect() failed: Connection refused (111)
bt_audio_service_open: connect() failed: Connection refused (111)
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
PortAudio version number = 1899
PortAudio version text = 'PortAudio V19-devel (built Feb 14 2015 11:51:22)'
Number of devices = 20
--------------------------------------- device #0
Name = HDA Intel PCH: ALC892 Analog (hw:0,0)
Host API = ALSA
Max inputs = 2, Max outputs = 6
Default low input latency = 0.0058
Default low output latency = 0.0087
Default high input latency = 0.0348
Default high output latency = 0.0348
Default sample rate = 44100.00
Supported standard sample rates
for half-duplex 16 bit 2 channel input =
44100.00, 48000.00, 96000.00, 192000.00
Supported standard sample rates
for half-duplex 16 bit 6 channel output =
None
Supported standard sample rates
for full-duplex 16 bit 2 channel input, 6 channel output =
None
--------------------------------------- device #1
Name = HDA Intel PCH: ALC892 Digital (hw:0,1)
Host API = ALSA
Max inputs = 0, Max outputs = 2
Default low input latency = -1.0000
Default low output latency = 0.0058
Default high input latency = -1.0000
Default high output latency = 0.0348
Default sample rate = 44100.00
Supported standard sample rates
for half-duplex 16 bit 2 channel output =
32000.00, 44100.00, 48000.00, 88200.00,
96000.00, 192000.00
--------------------------------------- device #2
Name = HDA Intel PCH: ALC892 Alt Analog (hw:0,2)
Host API = ALSA
Max inputs = 2, Max outputs = 0
Default low input latency = 0.0058
Default low output latency = -1.0000
Default high input latency = 0.0348
Default high output latency = -1.0000
Default sample rate = 44100.00
Supported standard sample rates
for half-duplex 16 bit 2 channel input =
44100.00, 48000.00, 96000.00, 192000.00
--------------------------------------- device #3
Name = HDA NVidia: HDMI 0 (hw:1,3)
Host API = ALSA
Max inputs = 0, Max outputs = 8
Default low input latency = -1.0000
Default low output latency = 0.0058
Default high input latency = -1.0000
Default high output latency = 0.0348
Default sample rate = 44100.00
Supported standard sample rates
for half-duplex 16 bit 8 channel output =
32000.00, 44100.00, 48000.00, 88200.00,
96000.00, 192000.00
--------------------------------------- device #4
Name = HDA NVidia: HDMI 0 (hw:1,7)
Host API = ALSA
Max inputs = 0, Max outputs = 8
Default low input latency = -1.0000
Default low output latency = 0.0058
Default high input latency = -1.0000
Default high output latency = 0.0348
Default sample rate = 44100.00
Supported standard sample rates
for half-duplex 16 bit 8 channel output =
32000.00, 44100.00, 48000.00, 88200.00,
96000.00, 192000.00
--------------------------------------- device #5
Name = HDA NVidia: HDMI 0 (hw:1,8)
Host API = ALSA
Max inputs = 0, Max outputs = 8
Default low input latency = -1.0000
Default low output latency = 0.0058
Default high input latency = -1.0000
Default high output latency = 0.0348
Default sample rate = 44100.00
Supported standard sample rates
for half-duplex 16 bit 8 channel output =
32000.00, 44100.00, 48000.00, 88200.00,
96000.00, 192000.00
--------------------------------------- device #6
Name = HDA NVidia: HDMI 0 (hw:1,9)
Host API = ALSA
Max inputs = 0, Max outputs = 8
Default low input latency = -1.0000
Default low output latency = 0.0058
Default high input latency = -1.0000
Default high output latency = 0.0348
Default sample rate = 44100.00
Supported standard sample rates
for half-duplex 16 bit 8 channel output =
32000.00, 44100.00, 48000.00, 88200.00,
96000.00, 192000.00
--------------------------------------- device #7
Name = sysdefault
Host API = ALSA
Max inputs = 128, Max outputs = 128
Default low input latency = 0.0213
Default low output latency = 0.0213
Default high input latency = 0.0213
Default high output latency = 0.0213
Default sample rate = 48000.00
Supported standard sample rates
for half-duplex 16 bit 128 channel input =
8000.00, 9600.00, 11025.00, 16000.00,
22050.00, 32000.00, 44100.00, 48000.00,
88200.00
Supported standard sample rates
for half-duplex 16 bit 128 channel output =
8000.00, 9600.00, 11025.00, 16000.00,
22050.00, 32000.00, 44100.00, 48000.00,
88200.00
Supported standard sample rates
for full-duplex 16 bit 128 channel input, 128 channel output =
8000.00, 9600.00, 11025.00, 16000.00,
22050.00, 32000.00, 44100.00, 48000.00,
88200.00
--------------------------------------- device #8
Name = front
Host API = ALSA
Max inputs = 0, Max outputs = 6
Default low input latency = -1.0000
Default low output latency = 0.0058
Default high input latency = -1.0000
Default high output latency = 0.0348
Default sample rate = 44100.00
Supported standard sample rates
for half-duplex 16 bit 6 channel output =
Test3c: pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0' failed.
Aborted (core dumped)
It crashes midway through listing the devices, when Pa_IsFormatSupported() is called. Google tells me that "pcm_params.c" refers to the ALSA library. Has anyone found a solution to this type of problem?
So I think I've found a solution. After the most recent error, I noticed the recommendation for a different audio issue here to restart the audio drivers in the following way:
pulseaudio -k && sudo alsa force-reload
I did it, and then tried running the compiled program, and got errors again (I think I was being impatient). I then did this command a second time, and now it works.
update: After a while, I do get the error again, and have to restart the drivers again.
Currently I am the maintainer of the Portaudio-linux host, and have just come across this question here. The same issue has been reported on the Portaudio mailing list, and investigated. The assert is in Alsa-lib, and has now been removed by the Alsa-developers in favour of an error return. See
http://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=67f73b0fab466e780dcc0442e19894a1cbedc43b
Certain devices seem to cause a problem with 6-channels on 'front' (and some other) PCMs. This is not a fault of Portaudio, but as it probes the capabilities of the devices and PCMs it exposes issues within the Alsa system. With the assert removed, it now just fails these capabilities.
I encountered the same problem and resolved it by fixing some faulty pcm definitions in /usr/share/alsa/pcm. In the route section towards the bottom of the file the card driver was referencing a different pcm then the one defined in the file.
Related
I've try to get count of NIC RX rings from my programs via ETHTOOL API and
command ETHTOOL_GCHANNELS, but program returns error: "Operation not supported."
Sample code:
echannels.cmd = ETHTOOL_GCHANNELS;
req.ifr_data = (void*)&echannels;
if (ioctl(sock, SIOCETHTOOL, &req) != 0)
ERR("Can't get %s channels info! %s", nic, strerror(errno));
else
rx_no = echannels.rx_count;
Also i've try to get it from ethtool "ethtool -l eth0" with the same result:
#ethtool -l eth0
Channel parameters for eth0:
Cannot get device channel parameters
: Operation not supported
, but in /proc/interrupts i see that NIC have multiple RX rings binded to different CPU cores.
Anybody can tell me right way to get count of RX rings from C code?
I was looking to get the ring counts of my NICs as well. After talking with someone more knowledgeable than I (who also wasn't figuring it out), we came to the agreement that you might have to check the specs for your NIC; that it doesn't seem to be something directly available through ethtool.
However, this post also shows that, by checking the indirection table, it can show the RX ring (but not TX ring) count:
$ sudo ethtool -x eth0
RX flow hash indirection table for eth3 with 2 RX ring(s):
0: 0 1 0 1 0 1 0 1
8: 0 1 0 1 0 1 0 1
16: 0 1 0 1 0 1 0 1
24: 0 1 0 1 0 1 0 1
However, on one of my machines I see:
$ sudo ethtool -x enp9s0
Cannot get RX ring count: Operation not supported
This is in spite of the documentation for the NIC saying both:
"The 82574L supports two transmit descriptor rings"
"Figure 26 shows the structure of the two receive descriptor rings."
Hopefully either the -x option or checking the documentation for your NIC will help. It doesn't seem to be consistently and directly accessible via ethtool.
I am having an issue with writing on a SD card when the frequency is 62.5 kHz.
TCCR0B = (TCCR0B & 0b11111000) | 0x01 - is what i used
I tried the original setting and it works but not when i changed it.
TCCR0B = (TCCR0B & 0b11111000) | 0x03 - original setting
Is there anything i can do to read/write on SD card when using 62.5 kHz? Reason why i need 62.5 kHz is for the PWM signal at pin 5 and 6.
I am using MPC 7555 controller. It has a 16 bit sigma delta ADC.
A signal called mic input is fed to this ADC pin. based upon the voltage , a PWM signal of same frequency of ADC signal sampling should be generated.
For e.g.
0.1 V = 2 percent
0.2 V = 4 percent
0.3 V = 6 percent....and so on
So, i thought the following logic -
5V - 0xFFFF in digital
0.1V - 1310
0.2V - 2620 and so on
So, dividing the digital value by 655 will give exact duty cycle value
1310/655 = 2
2620/655 = 4........
But digital pin could also show value of 1309 for 0.1 V which when divided by 655 would yield 1 and not 2.
Anyway i can avoid this or does any have a better solution, please share.
The task is to output PWM at the same rate as the ADC conversion rate.
Suppose the ADC conversion time is T (you can establish this by reading a free-run timer counter). And suppose the ADC conversion value is V. Then the PWM output time H spent "high" must be
H = T * V / 0xFFFF
Every time an ADC conversion is available, you (cancel any pending one-shot timer interrupt and) set the PWM output to 1 and trigger a one-shot timer at time H. When it interrupts, you set the PWM output to 0 (or the other way round if you have inverse logic).
If the input is 0x0000 or 0xFFFF you can employ an alternative strategy - set the output to 0 or 1, but don't deploy the one-shot timer.
To get the best fidelity in teh PWM signal, you would do better to work directly at the resolution of the PWM rather then calculate a percentage only to then convert that to a PWM count. Using integer percentage, you are effectively limiting your resolution to 6.64 bits per sample (i.e. log10(100)/log10(2)).
So let's say your PWM count per cycle is PWM_MAX, and your ADC maximum ADC_MAX, then the PWM high period would be:
pwm_high = adc_val * PWM_MAX / ADC_MAX ;
It is important to perform the multiplication first to avoid loss of information. If PWM_MAX is suficiently high, there is probably no need to worry about integer division rounding toward zero rather then to teh nearest integer, but if that is a concern (for low PWM_MAX ) then:
pwm_high = ((adc_val * PWM_MAX) + (ADC_MAX / 2)) / ADC_MAX ;
For example, soy your PWM_MAX is only 100 (i.e. the resolution truely is in integer percent), then in the first case:
pwm_high = 1310 * 100 / 0xFFFF = 1
and in the second:
pwm_high = ((1310 * 100) + 0x7FFF) / 0xFFFF = 2
However if PWM_MAX is a more suitable 4096 perhaps, then:
pwm_high = 1310 * 4096 / 0xFFFF = 81
or
pwm_high = ((1310 * 4096) + 0x7fff) / 0xFFFF = 82
With PWM_MAX at 4096 you have effectively 12 bits of resolution and will maintain much higher fidelity as well as directly calculating the correct PWM value.
From Microchip sample code
PR2 = 2083u; /* Timer2 Period, 19.2 kHz */
How does 2083u correspond to 19.2 kHz, which is
1 / 19.2E03 = 52.083u
They don't correspond at all. Mistake by Microchip?
PR2 = 2083U
makes TIMER2 trigger every 2083 CPU cycles. Calculating
52.083 us / 2083 = 25 ns
1 / 25 ns = 40 MHz
we can conclude that the processor is probably running at FCY = 40 MHz in the example.
The letter u in PR2 = 2038u; does not mean microseconds; it is a C language syntax that makes the integer literal unsigned. See Signedness (Wikipedia).
Setting PR2 to 2083 means that the timer triggers every 2084 (not 2083) clock cycles. When you calculate a timer period, you always have to subtract 1 because the timer value is zero-based.
We are getting very poor quality of voice during testing of a new
filtering application of us.
The application receives packets from kernel using netfilter_queue
library. Then insert the packets into a new user managed queue and
does some transformations on it, like concatenation of udp payload.
The network is healthy. Its inside our lab. And it does not drop
packets or anything .
In our app we do not forward packet immediately. After enough packet
received to increase rtp packetization time (ptime) the we forward the
message over raw socket and set dscp to be 10 so that this time
packets can escape iptable rules.
From client side the RTP stream analysis shows nearly every stream as
problematic. summery for some streams are given below :
Stream 1:
Max delta = 1758.72 ms at packet no. 40506
Max jitter = 231.07 ms. Mean jitter = 9.27 ms.
Max skew = -2066.18 ms.
Total RTP packets = 468 (expected 468) Lost RTP packets = 0
(0.00%) Sequence errors = 0
Duration 23.45 s (-22628 ms clock drift, corresponding to 281 Hz (-96.49%)
Stream 2:
Max delta = 1750.96 ms at packet no. 45453
Max jitter = 230.90 ms. Mean jitter = 7.50 ms.
Max skew = -2076.96 ms.
Total RTP packets = 468 (expected 468) Lost RTP packets = 0
(0.00%) Sequence errors = 0
Duration 23.46 s (-22715 ms clock drift, corresponding to 253 Hz (-96.84%)
Stream 3:
Max delta = 71.47 ms at packet no. 25009
Max jitter = 6.05 ms. Mean jitter = 2.33 ms.
Max skew = -29.09 ms.
Total RTP packets = 258 (expected 258) Lost RTP packets = 0
(0.00%) Sequence errors = 0
Duration 10.28 s (-10181 ms clock drift, corresponding to 76 Hz (-99.05%)
Any idea where should we look for the problem?