[Portaudio] Delta44

[Leif Asbrink]

Hello,

I am the author of Linrad, a program for SDR (software defined radio)

Linrad can be used for radio in duplex mode which means that latency
is utterly important.

In Linux, latency is no problem, ALSA or OSS provide adequate timing
and I can alternatively use Portaudio with ALSA for equivalent performance
except when I select the 32 bit format for Delta44. The 16 bit format
is OK, but the dynamic range with only 16 bits is not really satisfactory.
With ALSA or OSS (alsa-oss) I get perfect performance, but when I try
to use Portaudio, thre result is horrible. The error is not present
if I use the motherboard (intel) soundcard.

The reason why I added Portaudio into Linrad is that there is a need
to use ASIO drivers under Windows in order to avoid the stupid delay
associated with MME drivers. Unfortunately the same Portaudio
bug is present in Windows.

What I see is that the callback comes as expected. When I fill the
buffer with e.g. a squarewave of sampling rate/32 which should lead
to a square-wave at the Nyquist frequency divided by 32, the output
is quite, different. I see a burst of a squarewave at 10 times the
expected frequency (spanning 10% of the time) with zero over 90%
of the time.

For the moment my work-around is to select 16 bit data, but that
leads to a loss of dynamic range performance. Under Linux I do not need
Portaudio so Linux gives full performance, but under Windows there
are problems with various extra processes adding delay when other
than ASIO drivers are used.

I have tried pa_stable_v19_20111121.tgz and pa_stable_v19_20140130.tgz
and both of them behave the same way.


- Leif -

[Ross Bencina]

Hello Leif,

Thanks for writing. I'm not sure whether I fully understand your report.
I have tried to interpret it below. Please let me know whether I got
anything wrong. I've also included some extra questions.

Post by Leif Asbrink
In Linux, latency is no problem, ALSA or OSS provide adequate timing
and I can alternatively use Portaudio with ALSA for equivalent
performance except when I select the 32 bit format for Delta44. The
16 bit format is OK, but the dynamic range with only 16 bits is not
really satisfactory. With ALSA or OSS (alsa-oss) I get perfect
performance, but when I try to use Portaudio, thre result is
horrible. The error is not present if I use the motherboard (intel)
soundcard.

It is not clear exactly what you mean. Please confirm if my
interpretation below is correct:

With PortAudio/ALSA:

Delta44:

- 16-bit integer I/O works perfectly

- 32-bit integer is "horrible" (but what is the exact error? is it the
same as the Windows case below or some other error?)

Questions:

Are you using mono or stereo? Do you see the same problem in both cases?

Have you tried other formats such as 32-bit float?


Intel Motherboard:

- 16-bit integer I/O works perfectly
- 32-bit integer I/O works perfectly

Post by Leif Asbrink
What I see is that the callback comes as expected. When I fill the
buffer with e.g. a squarewave of sampling rate/32 which should lead
to a square-wave at the Nyquist frequency divided by 32, the output
is quite, different. I see a burst of a squarewave at 10 times the
expected frequency (spanning 10% of the time) with zero over 90%
of the time.

What do you mean you "see" the signal? Are you inspecting on an
oscilloscope, or another computer? Are you able to post a recording of
the output?

Does the duration of the zeros or the frequency multiplication of the
output relate to the callback buffer size or latency that you select
with PortAudio?

Once again: are you using mono or stereo?

On Windows does 16-bit work with the Delta44?

Do you see the same problem with all sound cards, or just the Delta44?

What sample rate have you selected with PortAudio?

Thank you,

Ross

[Leif Asbrink]

Hello Ross,

Post by Ross Bencina
It is not clear exactly what you mean. Please confirm if my
- 16-bit integer I/O works perfectly
- 32-bit integer is "horrible" (but what is the exact error? is it the
same as the Windows case below or some other error?)

My Windows system is currently broken. I can not say anything
about it for sure at the moment. The case below was actually
Linux (Debian)

Post by Ross Bencina
Are you using mono or stereo? Do you see the same problem in both cases?

It is the same in both cases.

Post by Ross Bencina
Have you tried other formats such as 32-bit float?

No.

Post by Ross Bencina
- 16-bit integer I/O works perfectly
- 32-bit integer I/O works perfectly

Yes.

Post by Ross Bencina

Post by Leif Asbrink
What I see is that the callback comes as expected. When I fill the
buffer with e.g. a squarewave of sampling rate/32 which should lead
to a square-wave at the Nyquist frequency divided by 32, the output
is quite, different. I see a burst of a squarewave at 10 times the
expected frequency (spanning 10% of the time) with zero over 90%
of the time.

What do you mean you "see" the signal? Are you inspecting on an
oscilloscope, or another computer? Are you able to post a recording of
the output?

I look at an oscilloscope. I could make a video on youtube if you
can not immediately reproduce.

Post by Ross Bencina
Does the duration of the zeros or the frequency multiplication of the
output relate to the callback buffer size or latency that you select
with PortAudio?

I select latency=1. It works fine with 16 bit format and with
all formats on the motherboard (Intel) soundcard.
I see no difference (except more delay) when I select higher
latency.
The buffer size does not matter. I select differentbuffer sizes,
but I always get 10% of the output samples containing all the data with 90%
of the output containing zeroes.

Post by Ross Bencina
Once again: are you using mono or stereo?

Both of them have the same problem.

In mono the signal comes out from channel 1 AND channel 2.
If I want a single channel, I have to open two channels
and send zeroes into one of them.

Post by Ross Bencina
On Windows does 16-bit work with the Delta44?

Yes. (But I am not 100% sure 32 bit is broken and I can not verify
that at the moment. Have to repair my Windows system first...)

Post by Ross Bencina
Do you see the same problem with all sound cards, or just the Delta44?

No, Under Linux I do not see any problem with the motherboard soundcard
(Intel) which works fine in Portaudio with 2 as well as 4 byte data
format under Linux.

Post by Ross Bencina
What sample rate have you selected with PortAudio?

96 kHz normally, but the problem is the same at other rates.

I am a specialist in radio. The oddities of sound systems are
confusing to me. Very low latency without mixers, resamplers,
equalizers and other stuff is needed.

When we speak into a microphone, the maximum allowed delay is
about 100ms. That is from microphone to antenna and back from the
antenna to the headphones. This is doable, but not with the 120
ms of extra delay in a standard Windows 7 environment.

Today full duplex in ssb is available under Linux only, ALSA
is fine. In Windows I need Portaudio to get the ASIO drivers,
but dynamic range is degraded when I have to use 16 bit only.
There is sideband noise due to the degraded S/N at 16 bit.

Regards

Leif

[g***@novadsp.com]

Hello Leif

I am a specialist in radio. The oddities of sound systems are confusing to

me. Very low latency without mixers, resamplers, equalizers and other stuff
is needed.

When we speak into a microphone, the maximum allowed delay is about 100ms.

That is from microphone to antenna and back from the antenna to the
headphones. This is doable, but not with the 120 ms of extra delay in a

standard Windows 7 environment.

Irrespective of other problems you should try using the WASAPI interface.
This is native to (and works correctly with) Windows 7 and later, thus no
need for ASIO. You should get latencies in the order of 10ms or so.

If you open the audio device (your Delta 44) in exclusive mode you will get
bit-prefect reproduction: no resampling, no filtering or any other 'dings'
in the mix.

In case you do not have them Windows 7 and later drivers are somewhere close
to here: http://www.m-audio.com/support/download/drivers/delta-6.0.8


HTH

Jerry

[Alberto di Bene]

_______________________________________________
Portaudio mailing list
***@music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio

[Leif Asbrink]

Hello Alberto,

Post by Leif Asbrink
In Windows I need Portaudio to get the ASIO drivers,
Why ? If you download the ASIO SDK from the Steinberg site you can easily
write code that interfaces directly with the native ASIO drivers for the Delta 44
card. I know, I did it in Winrad and it works. And the complexity is about the same
as interfacing with the MME subsystem of Windows.

Hmmm, someone else, Pierre Vanhoucke, implemented Portaudio for me and
it has served well for the receiver which sends 16 bit data to the
loudspeakers. Now, when I am adding transmit functions I want to use
the perhaps 10 dB lower noise floor I can get by using more bits.

Luckily it seems to be no problem under Windows although problems
in my own code makes problems in Windows. The interface to ASIO
via Portaudio seems OK however.

Many soundcards come without ASIO. They may have WDM-KS or WASAPI
instead so I would have to write native support for them also if
I would skip Portaudio....

73

Leif

[Alan Horstmann]

Hi Leif,

Post by Leif Asbrink
In Linux, latency is no problem, ALSA or OSS provide adequate timing
and I can alternatively use Portaudio with ALSA for equivalent performance
except when I select the 32 bit format for Delta44. The 16 bit format
is OK, but the dynamic range with only 16 bits is not really satisfactory.
With ALSA or OSS (alsa-oss) I get perfect performance, but when I try
to use Portaudio, thre result is horrible. The error is not present
if I use the motherboard (intel) soundcard.
The reason why I added Portaudio into Linrad is that there is a need
to use ASIO drivers under Windows in order to avoid the stupid delay
associated with MME drivers. Unfortunately the same Portaudio
bug is present in Windows.
What I see is that the callback comes as expected. When I fill the
buffer with e.g. a squarewave of sampling rate/32 which should lead
to a square-wave at the Nyquist frequency divided by 32, the output
is quite, different. I see a burst of a squarewave at 10 times the
expected frequency (spanning 10% of the time) with zero over 90%
of the time.

The Delta44 is based on the 'envy24' chipset, I believe, as the Delta1010,
DMX6fire and others; I have 2 such. I am fairly sure I have captured in
32-bit successfully at some time in the past (using Linux, Audacity).

It may be relevant or not that the envy24 ALWAYS transfers a fixed data
format/channels at the hardware level. There are always 10 playback and 12
capture channels, of 24-bit samples (LE) packed into 32-bits. I know this
causes problems on Linux using raw ALSA (not Portaudio) as it is not possible
to write 2 channels to the hardware (hw:n) devices. ASIO is also a low-level
driver is it not? So Portaudio should be doing channel adaption. There is
also possibly confusion over the data number of bits.

It should be fairly straightforward to narrow down the issue, hopefully!

Regards

Alan

[Phil Burk]

The Int32_To_Int24() conversion function looks OK to me.

But I notice that the conversion function Int32_To_Int24_Dither() is not
implemented. If the destination buffer is not cleared then that could
result in random noise being output, which would qualify as "horrible".

Try using the paDitherOff flag when you open your stream. Does that help?

Phil Burk

Post by Alan Horstmann
Hi Leif,

Post by Leif Asbrink
In Linux, latency is no problem, ALSA or OSS provide adequate timing
and I can alternatively use Portaudio with ALSA for equivalent

performance

Post by Leif Asbrink
except when I select the 32 bit format for Delta44. The 16 bit format
is OK, but the dynamic range with only 16 bits is not really

satisfactory.

Post by Leif Asbrink
With ALSA or OSS (alsa-oss) I get perfect performance, but when I try
to use Portaudio, thre result is horrible. The error is not present
if I use the motherboard (intel) soundcard.
The reason why I added Portaudio into Linrad is that there is a need
to use ASIO drivers under Windows in order to avoid the stupid delay
associated with MME drivers. Unfortunately the same Portaudio
bug is present in Windows.
What I see is that the callback comes as expected. When I fill the
buffer with e.g. a squarewave of sampling rate/32 which should lead
to a square-wave at the Nyquist frequency divided by 32, the output
is quite, different. I see a burst of a squarewave at 10 times the
expected frequency (spanning 10% of the time) with zero over 90%
of the time.

The Delta44 is based on the 'envy24' chipset, I believe, as the Delta1010,
DMX6fire and others; I have 2 such. I am fairly sure I have captured in
32-bit successfully at some time in the past (using Linux, Audacity).
It may be relevant or not that the envy24 ALWAYS transfers a fixed data
format/channels at the hardware level. There are always 10 playback and 12
capture channels, of 24-bit samples (LE) packed into 32-bits. I know this
causes problems on Linux using raw ALSA (not Portaudio) as it is not possible
to write 2 channels to the hardware (hw:n) devices. ASIO is also a low-level
driver is it not? So Portaudio should be doing channel adaption. There is
also possibly confusion over the data number of bits.
It should be fairly straightforward to narrow down the issue, hopefully!
Regards
Alan
_______________________________________________
Portaudio mailing list
http://music.columbia.edu/mailman/listinfo/portaudio

[Leif Asbrink]

Hello Phil,

Post by Phil Burk
The Int32_To_Int24() conversion function looks OK to me.
But I notice that the conversion function Int32_To_Int24_Dither() is not
implemented. If the destination buffer is not cleared then that could
result in random noise being output, which would qualify as "horrible".

No, the result is horrible - but it is not random. What I get is
the data that I have stored in the buffer - but it is clocked
at 960 kHz, 10 times faster than the value I specified. A buffer that
should last for 10 ms is emptied in a single ms and the ramaining
9 ms have zero output.

It looks like the card thinks there are 10 channels and that a multiplexor
that should distribute the data points over 10 channels sends all the
data to a single channel.

The above is when I select one channel. When I select two channels
the data lasts twice as long and is thus clocked to the DA converters
at 5*96 kHz. The time-compressed waveforms are what I have stored
in the buffer. Even data points to one channel and odd data points to
the other.

My Windows system is now repaired and it turns out I was mistaken.
The error occurs under Linux only. Very good for me since there
is no need for Portaudio under Linux in my project:-)

Post by Phil Burk
Try using the paDitherOff flag when you open your stream. Does that help?

The paDitherOff flag makes no difference.

Leif

[Phil Burk]

Post by Leif Asbrink
10 times faster than the value I specified.

Yes. It does sound like the device is running with more channels than your
app is using. Do you hear sound on all output channels.

What happens when you run the "bin/pa_dev" app? it will print how many
channels it thinks the hardware has.

Please double check the number you are using when you open the stream.

Phil Burk

Post by Leif Asbrink
Hello Phil,

Post by Phil Burk
The Int32_To_Int24() conversion function looks OK to me.
But I notice that the conversion function Int32_To_Int24_Dither() is not
implemented. If the destination buffer is not cleared then that could
result in random noise being output, which would qualify as "horrible".

No, the result is horrible - but it is not random. What I get is
the data that I have stored in the buffer - but it is clocked
at 960 kHz, 10 times faster than the value I specified. A buffer that
should last for 10 ms is emptied in a single ms and the ramaining
9 ms have zero output.
It looks like the card thinks there are 10 channels and that a multiplexor
that should distribute the data points over 10 channels sends all the
data to a single channel.
The above is when I select one channel. When I select two channels
the data lasts twice as long and is thus clocked to the DA converters
at 5*96 kHz. The time-compressed waveforms are what I have stored
in the buffer. Even data points to one channel and odd data points to
the other.
My Windows system is now repaired and it turns out I was mistaken.
The error occurs under Linux only. Very good for me since there
is no need for Portaudio under Linux in my project:-)

Post by Phil Burk
Try using the paDitherOff flag when you open your stream. Does that help?

The paDitherOff flag makes no difference.
Leif
_______________________________________________
Portaudio mailing list
http://music.columbia.edu/mailman/listinfo/portaudio

[Leif Asbrink]

Hi Phil,

Post by Phil Burk

Post by Leif Asbrink
10 times faster than the value I specified.

Yes. It does sound like the device is running with more channels than your
app is using. Do you hear sound on all output channels.

When I open with one channel, sampling rate is 10 times too high.
Channel 1 and channel 2 contain identical data, channels 3 and 4 are silent.

When I open with two channels, sampling rate is 5 times too high
and I get the desired different outputs in the two channels
and silence in channels 3 and 4.

I can extrapolate and guess that if I would open with 10 channels
I would get the correct signals in the four physically existing channels.

Leif

Post by Phil Burk
What happens when you run the "bin/pa_dev" app? it will print how many
channels it thinks the hardware has.
Please double check the number you are using when you open the stream.
Phil Burk

Post by Leif Asbrink
Hello Phil,

Post by Phil Burk
The Int32_To_Int24() conversion function looks OK to me.
But I notice that the conversion function Int32_To_Int24_Dither() is not
implemented. If the destination buffer is not cleared then that could
result in random noise being output, which would qualify as "horrible".

No, the result is horrible - but it is not random. What I get is
the data that I have stored in the buffer - but it is clocked
at 960 kHz, 10 times faster than the value I specified. A buffer that
should last for 10 ms is emptied in a single ms and the ramaining
9 ms have zero output.
It looks like the card thinks there are 10 channels and that a multiplexor
that should distribute the data points over 10 channels sends all the
data to a single channel.
The above is when I select one channel. When I select two channels
the data lasts twice as long and is thus clocked to the DA converters
at 5*96 kHz. The time-compressed waveforms are what I have stored
in the buffer. Even data points to one channel and odd data points to
the other.
My Windows system is now repaired and it turns out I was mistaken.
The error occurs under Linux only. Very good for me since there
is no need for Portaudio under Linux in my project:-)

Post by Phil Burk
Try using the paDitherOff flag when you open your stream. Does that help?

The paDitherOff flag makes no difference.
Leif
_______________________________________________
Portaudio mailing list
http://music.columbia.edu/mailman/listinfo/portaudio

[Alan Horstmann]

Hi guys,

I do seem to be able to reproduce this problem, quickly running a test using
patest_sine_time (modified to allow selecting the output device, and
hard-coding the formats). See the attached screenshot, capturing the result
back with Audacity. [For the observant, this is a special Audacity with
multi-channel features.] (Note the capturing is not causing the issue.) It
is the same on a 64-bit machine, DMX6fire and 32-bit machine with ST-Audio
DSP2000.

The top 2 channels are with PaInt32, the lower ones PaFloat32. So something
is very wrong. Using the sine test shows the bad data is not simply bursts
of one channel. Unfortunately I do not have opportunity to track this down
ATM, and thought I would post these hasty results in case anyone has ideas.
There is perhaps some link between the channel adaption and format
conversion. I am quite surprised not to have come across this previously!

A separate test with paex_record was successful in capturing raw data in both
float32 and int32 formats, confirming Leif's results.

Regards

Alan

[Alan Horstmann]

Post by Alan Horstmann
I do seem to be able to reproduce this problem, quickly running a test
using patest_sine_time (modified to allow selecting the output device, and
hard-coding the formats). See the attached screenshot, capturing the
result back with Audacity

The test was too hasty - the data format wasn't correctly computed. With that
fixed, a new screenshot attached. As Leif reported, the data is played out
too fast, probably due to a 10:2 channels mismatch. Will investigate further
when I can.

Regards

Alan

[Alan Horstmann]

Post by Alan Horstmann

Post by Alan Horstmann
I do seem to be able to reproduce this problem, quickly running a test
using patest_sine_time (modified to allow selecting the output device,
and hard-coding the formats). See the attached screenshot, capturing the
result back with Audacity

The test was too hasty - the data format wasn't correctly computed. With
that fixed, a new screenshot attached. As Leif reported, the data is
played out too fast, probably due to a 10:2 channels mismatch. Will
investigate further when I can.

Have looked at this a bit more; it turns out to be the output mirror of a
pa_process.c capture mono/stereo bug that was fixed in svn1913. When the
output and host formats are the same output conversion is skipped but this
prevents output channel adaption. The Linux 'hw:n' devices present exactly
what the card hardware provides; in the 'envy24' case that is 10 output
channels, Int32, so adaption is needed in Portaudio for all but 10 channel
output. So the host and user num channels need to be checked also.

A proposed patch is below (and attached). Leif, can you try this and confirm
whether it fixes the issue you reported, please. I would add that projects
like Linrad are ideal uses for Portaudio, since you only have to code once
for all platforms.

--- a/src/common/pa_process.c (spv:repo)
+++ b/src/common/pa_process.c (local)
@@ -834,8 +834,10 @@
{
if( bp->userOutputIsInterleaved )
{
- /* process host buffer directly, or use temp buffer if formats differ or host buffer non-interleaved */
- if( bp->userOutputSampleFormatIsEqualToHost && bp->hostOutputIsInterleaved )
+ /* process host buffer directly, or use temp buffer if formats differ or host buffer non-interleaved,
+ * or if the number of channels differs between the host (set in stride) and the user */
+ if( bp->userOutputSampleFormatIsEqualToHost && bp->hostOutputIsInterleaved
+ && bp->outputChannelCount == hostOutputChannels[0].stride )
{
userOutput = hostOutputChannels[0].data;
skipOutputConvert = 1;


Regards

Alan

[Leif Asbrink]

Hello Alan,

Post by Alan Horstmann
A proposed patch is below (and attached). Leif, can you try this and confirm
whether it fixes the issue you reported, please. I would add that projects
like Linrad are ideal uses for Portaudio, since you only have to code once
for all platforms.

YES!!

The patch fixes Delta44 with ALSA:-)

I agree Portaudio should be ideal for Linrad (and many other projects)
but there are some severe problems.

Under Windows, the Portaudio interface to MME and Windows Direct Sound
is useless. Can only be used with very big buffers and associated
far too long latency.

Portaudio with ASIO, WDM-KS and WASAPI is OK and the very reason why
I have implemented Portaudio in Linrad. Having it I also want to see
it working in Linux which it does now:-)

There is a problem however. Linrad tries to investigate the
native properties of a device so the user should not select
a sampling speed that is not supported by hardware. Under Debian
this causes crasches on several devices. (Fedora is OK.)

A call to Pa_IsFormatSupported(NULL, &outputParameters, samprate );
will cause a crasch for a certain samprate. The Linrad log file
is like this:
TESTING PORTAUDIO DEVICE 10 FOR Rx output

id=10 device=front hostapi=ALSA max_input_chan=0 max_output_chan=6
Testing 0 8000.000000 err=-9997 Invalid sample rate
Testing 1 9600.000000 err=-9997 Invalid sample rate
Testing 2 11025.000000 err=-9997 Invalid sample rate
Testing 3 12000.000000 err=-9997 Invalid sample rate
Testing 4 16000.000000 err=-9997 Invalid sample rate
Testing 5 22050.000000 err=-9997 Invalid sample rate
Testing 6 24000.000000 err=-9997 Invalid sample rate
Testing 7 32000.000000 err=-9997 Invalid sample rate
Testing 8 44100.000000

This means that the call to Pa_IsFormatSupported did not return
when samprate=44100.

The terminal window (stderr) shows this:
***@Xeon:/home/dsp# ./xlinrad64
ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition
'cards.HDA-Intel.pcm.rear.0:CARD=0'
ALSA lib conf.c:4259:(_snd_config_evaluate) function snd_func_refer returned
error: No such file or directory
ALSA lib conf.c:4738:(snd_config_expand) Evaluate error: No such file or
directory
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM rear
ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition
'cards.HDA-Intel.pcm.center_lfe.0:CARD=0'
ALSA lib conf.c:4259:(_snd_config_evaluate) function snd_func_refer returned
error: No such file or directory
ALSA lib conf.c:4738:(snd_config_expand) Evaluate error: No such file or
directory
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM center_lfe
ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition
'cards.HDA-Intel.pcm.side.0:CARD=0'
ALSA lib conf.c:4259:(_snd_config_evaluate) function snd_func_refer returned
error: No such file or directory
ALSA lib conf.c:4738:(snd_config_expand) Evaluate error: No such file or
directory
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM side
ALSA lib pcm_route.c:947:(find_matching_chmap) Found no matching channel map
ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect:
Connection refused

ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect:
Connection refused

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
xlinrad64: pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0'
failed.
Aborted

For my own experimenting I just disable testing of all the
failing devices. That is not acceptable for a distribution version
however. If somethings goes wrong I need a return with an error code,
not a crasch!!

Leif

[Alan Horstmann]

Post by Leif Asbrink
Hello Alan,

Post by Alan Horstmann
A proposed patch is below (and attached). Leif, can you try this and
confirm whether it fixes the issue you reported, please. I would add
that projects like Linrad are ideal uses for Portaudio, since you only
have to code once for all platforms.

YES!!
The patch fixes Delta44 with ALSA:-)

Thanks for the confirmation, Leif. As for the subsequent issue, could you
start a new thread (new subject) to pursue that one. It's hitting an assert
in Alsa-lib, it seems. So let's get a fresh start on the circumstances to
reproduce that one (all soundcards or just some?), operating systems
(versions, Linux kernel versions etc) and any details available


Ross, Phil, are you OK with this pa_process.c fix going into trunk?


Regards

Alan

Post by Leif Asbrink
I agree Portaudio should be ideal for Linrad (and many other projects)
but there are some severe problems.
Under Windows, the Portaudio interface to MME and Windows Direct Sound
is useless. Can only be used with very big buffers and associated
far too long latency.
Portaudio with ASIO, WDM-KS and WASAPI is OK and the very reason why
I have implemented Portaudio in Linrad. Having it I also want to see
it working in Linux which it does now:-)
There is a problem however. Linrad tries to investigate the
native properties of a device so the user should not select
a sampling speed that is not supported by hardware. Under Debian
this causes crasches on several devices. (Fedora is OK.)
A call to Pa_IsFormatSupported(NULL, &outputParameters, samprate );
will cause a crasch for a certain samprate. The Linrad log file
TESTING PORTAUDIO DEVICE 10 FOR Rx output
id=10 device=front hostapi=ALSA max_input_chan=0 max_output_chan=6
Testing 0 8000.000000 err=-9997 Invalid sample rate
Testing 1 9600.000000 err=-9997 Invalid sample rate
Testing 2 11025.000000 err=-9997 Invalid sample rate
Testing 3 12000.000000 err=-9997 Invalid sample rate
Testing 4 16000.000000 err=-9997 Invalid sample rate
Testing 5 22050.000000 err=-9997 Invalid sample rate
Testing 6 24000.000000 err=-9997 Invalid sample rate
Testing 7 32000.000000 err=-9997 Invalid sample rate
Testing 8 44100.000000
This means that the call to Pa_IsFormatSupported did not return
when samprate=44100.
ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition
'cards.HDA-Intel.pcm.rear.0:CARD=0'
ALSA lib conf.c:4259:(_snd_config_evaluate) function snd_func_refer
returned error: No such file or directory
ALSA lib conf.c:4738:(snd_config_expand) Evaluate error: No such file or
directory
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM rear
ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition
'cards.HDA-Intel.pcm.center_lfe.0:CARD=0'
ALSA lib conf.c:4259:(_snd_config_evaluate) function snd_func_refer
returned error: No such file or directory
ALSA lib conf.c:4738:(snd_config_expand) Evaluate error: No such file or
directory
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM center_lfe
ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition
'cards.HDA-Intel.pcm.side.0:CARD=0'
ALSA lib conf.c:4259:(_snd_config_evaluate) function snd_func_refer
returned error: No such file or directory
ALSA lib conf.c:4738:(snd_config_expand) Evaluate error: No such file or
directory
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM side
ALSA lib pcm_route.c:947:(find_matching_chmap) Found no matching channel
Connection refused
Connection refused
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
xlinrad64: pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >=
0' failed.
Aborted
For my own experimenting I just disable testing of all the
failing devices. That is not acceptable for a distribution version
however. If somethings goes wrong I need a return with an error code,
not a crasch!!
Leif

[Ross Bencina]

Post by Alan Horstmann
Ross, Phil, are you OK with this pa_process.c fix going into trunk?

Hi Alan,

Can you explain why/when the fix is needed?

A quick glance makes me think that maybe PA/ALSA is not configuring the
buffer processor correctly. It looks as though the case you are patching
could only arise if the PA client channel count doesn't match the host
channel count. Does the buffer processor even support that? (sorry for
stupid questions, I don't have the bandwidth to spool in all the details
right now).

Thanks,

Ross.

[Alan Horstmann]

Hi Ross,

Post by Ross Bencina

Post by Alan Horstmann
Ross, Phil, are you OK with this pa_process.c fix going into trunk?

Can you explain why/when the fix is needed?
A quick glance makes me think that maybe PA/ALSA is not configuring the
buffer processor correctly. It looks as though the case you are patching
could only arise if the PA client channel count doesn't match the host
channel count. Does the buffer processor even support that? (sorry for
stupid questions, I don't have the bandwidth to spool in all the details
right now).

The issue is indeed only when the host channel count doesn't match the
client/user channel count. If the formats also differ then all the necessary
adaption takes place in the conversion process and all is well (hence float32
and int16 are fine). But if the formats are the same (int32 here) the
conversion is skipped at present, which scuppers the channel adaption.

When I investigated the mono/stereo bug that was fixed in svn1913, which has
essentially the same cause but for capture not playback, I traced the process
fairly thoroughly, and I think the fix was considered fine. With this
playback issue I took a guess that it was a similar cause and put the
equivalent change on the playback side - and verified it did fix the issue
here. But I have not gone through the complete detailed analysis. I figure
that both fixes should be in place (or neither). But I may have missed
something and am open to there being other ways to achieve the channel
adaption.

Regards

Alan

[Ross Bencina]

Hi Alan,

Post by Alan Horstmann
When I investigated the mono/stereo bug that was fixed in svn1913, which has
essentially the same cause but for capture not playback, I traced the process
fairly thoroughly, and I think the fix was considered fine. With this
playback issue I took a guess that it was a similar cause and put the
equivalent change on the playback side - and verified it did fix the issue
here. But I have not gone through the complete detailed analysis. I figure
that both fixes should be in place (or neither). But I may have missed
something and am open to there being other ways to achieve the channel
adaption.

That's good enough for me to say go ahead and apply the patch.

That said,

Post by Alan Horstmann
The issue is indeed only when the host channel count doesn't match
the client/user channel count.

I can see how for input, the buffer processor could easily handle any
number of host input channels (so long as it gets informed about enough
of them to fulfill the client channel requirements it shouldn't matter
if there are other ignored channels).

But for output, I don't really understand how PA/ALSA is getting away
with it.

Which case are we discussing:

a) ALSA device opened channel count > PA client channel count

or

b) ALSA device opened channel count < PA client channel count

?

Thanks,

Ross.

[Alan Horstmann]

Post by Ross Bencina

Post by Alan Horstmann
The issue is indeed only when the host channel count doesn't match
the client/user channel count.

I can see how for input, the buffer processor could easily handle any
number of host input channels (so long as it gets informed about enough
of them to fulfill the client channel requirements it shouldn't matter
if there are other ignored channels).
But for output, I don't really understand how PA/ALSA is getting away
with it.
a) ALSA device opened channel count > PA client channel count
or
b) ALSA device opened channel count < PA client channel count

This is 'a)', the user is outputting 1 or 2 channels to an Alsa device that
has 10 channels. The other 9 or 8 channels do seem to be filled with silence
OK. Bear in mind that when both channels and formats differ the adaption is
successfully happening this way at present. So for example in Audacity on
Linux the bug is masked with these soundcards (I believe) because it always
uses float32 internally.

Regards

Alan

[Phil Burk]

Hi Alan,

I think it is a good patch. Thanks for figuring that out and fixing it.

The other 9 or 8 channels do seem to be filled with silence.

By "seem" do you mean that you saw code that wrote zeros, or the extra
channels were silent when you listened to it? Sometimes memory is randomly
zero when allocated but sometimes not.

Phil Burk

[Alan Horstmann]

Hi Phil,

Post by Phil Burk
I think it is a good patch. Thanks for figuring that out and fixing it.

The other 9 or 8 channels do seem to be filled with silence.

By "seem" do you mean that you saw code that wrote zeros, or the extra
channels were silent when you listened to it? Sometimes memory is randomly
zero when allocated but sometimes not.

Initially, just the latter - the envy24 chipset has a dedicated mixer util in
Alsa (envy24control) which also shows the signal level on each channel (due
to the chip's inbuilt peak monitoring), and these show nothing. But I can
see that the temp buffer is zeroed after allocation in
'PaUtil_InitializeBufferProcessor()', and it has been working fine upto now
as long as the format is also being converted.

Regards

Alan

[Ross Bencina]

But I can see that the temp buffer is zeroed after allocation in
'PaUtil_InitializeBufferProcessor()', and it has been working fine
upto now as long as the format is also being converted.

Hi Alan,

Your comment above doesn't confirm that the unused host output channels
are guaranteed zero.

My understanding is that the unused host buffer channels are never
touched by the buffer processor -- so it doesn't matter what's in the
temp buffer. The buffer processor has no concept of host channels being
different from client channels. It assumes the channel counts match.

I get the impression that you have 1 or 2 host output channels being
handled by the buffer processor, and ~8 not being handled by the buffer
processor at all.

The main way to check that I'm wrong is to confirm that all 10 (or
whatever) Delta44 output channel buffers are being registered with the
buffer processor. My impression is that's not the case, only 2 are being
registered (but with the correct stride). The other host output buffers
are just left with whatever data is in them.

I'm kinda guessing here, but that's my impression.

Thanks,

Ross.

[Alan Horstmann]

Hi Ross,

Post by Ross Bencina

But I can see that the temp buffer is zeroed after allocation in
'PaUtil_InitializeBufferProcessor()', and it has been working fine
upto now as long as the format is also being converted.

Your comment above doesn't confirm that the unused host output channels
are guaranteed zero.

That is a good point.

Post by Ross Bencina
My understanding is that the unused host buffer channels are never
touched by the buffer processor -- so it doesn't matter what's in the
temp buffer. The buffer processor has no concept of host channels being
different from client channels. It assumes the channel counts match.
I get the impression that you have 1 or 2 host output channels being
handled by the buffer processor, and ~8 not being handled by the buffer
processor at all.
The main way to check that I'm wrong is to confirm that all 10 (or
whatever) Delta44 output channel buffers are being registered with the
buffer processor. My impression is that's not the case, only 2 are being
registered (but with the correct stride). The other host output buffers
are just left with whatever data is in them.
I'm kinda guessing here, but that's my impression.

OK, you made me investigate further! (No bad thing, really.)

The unused channels are zeroed within the Alsa-host code in:

'PaAlsaStreamComponent_DoChannelAdaption()'

using a memset(), which is after the buffer processing. Maybe Alsa is the
only host that will encounter this condition?

Regards

Alan

[Ross Bencina]

Post by Alan Horstmann
'PaAlsaStreamComponent_DoChannelAdaption()'
using a memset(), which is after the buffer processing.

Hi Alan,

I took a look at PaAlsaStreamComponent_DoChannelAdaption and yes, I
agree, the code appears to be zeroing the unused channels. Hard to say
whether using memset there is the most efficient option, but at least
they're zeroed. So Phil and my concern is addressed.

Post by Alan Horstmann
Maybe Alsa is the only host that will encounter this condition?

The host APIs that I am familiar with will open the native stream with
the client-specified number of channels. I know of no other host API
that will try to open more channels than the user specified. As I
understand it, ALSA requires you to open all device channels, is that
the reason for this?

I imagine that the buffer processor code was written under the
assumption that the host and client would have the same number of
channels (and consequently the same stride). As they don't, I can see
why the patch is needed.

Perhaps the check for stride should have a comment, something like:

/* needed for e.g. ALSA where host stride may not match client stride */

If you add that, please could you add it for input case too?

Many thanks for all your hard work,

Ross.

[Alan Horstmann]

Post by Ross Bencina

Post by Alan Horstmann
Maybe Alsa is the only host that will encounter this condition?

The host APIs that I am familiar with will open the native stream with
the client-specified number of channels. I know of no other host API
that will try to open more channels than the user specified. As I
understand it, ALSA requires you to open all device channels, is that
the reason for this?

Alsa has several layers. The lowest is the kernel-level drivers for each
soundcard, whose job (as I understand it) is to operate the card and make
available what-ever the hardware provides, raw. Alsa-lib then provides a
user-level interface which is the public API. It contains a plugin mechanism
for adding functionality such as format conversion, mixing, channel mapping
etc through the various 'pcm' streams (often wrongly referred to as devices).

When (using the Alsa-lib API) a 'hw:x' pcm is opened no plugins are involved,
and so only the cards raw capabilities are available. Opening instead
'plughw:x' would add all the basic conversion capabilities, normally
including a basic samplerate conversion.

Since 'expert' linux audio users are always wary of corruption due to unwanted
conversions, there has been a tendency to always use the 'hx:x' pcms (closer
to the metal) thereby restricting to the soundcards raw capabilities - and
this carries over to Portaudio users. This lead to the endianess problem
with USB 'Audio4DJ' unit. Here (Delta44) the chipset has a fixed data
transfer - it cannot use less channels - and so the raw 'hw:x' pcm has the
same restriction. The plughw:x would not have this limitation at all.

However, there is an extra twist here in that the 'plughw' capabilities are
not probed by Portaudio separately from 'hw', so it would be treated as
having min channels 10, and 10 host channels will be opened, with the
adaption done by Portaudio. That is not a particular problem since it avoids
it being done by Alsa-lib.

Hope that clarifies a little!?

Regards

Alan

[Ross Bencina]

Hi Alan,

Post by Alan Horstmann
Hope that clarifies a little!?

A little, yes, thanks :)

Post by Alan Horstmann
restricting to the soundcards raw capabilities - and
this carries over to Portaudio users. This lead to the endianess
problem with USB 'Audio4DJ' unit.

I'm looking at adding byte swapping and shifting to pa_converters.c

I'm working on a source code generator that can spit out all of the
different converter functions by composing primitive operations.
Hopefully it will be more practical to work on than the current code.
But like all things PortAudio, who knows when it will be finished.

Ross.

[Alan Horstmann]

Post by Ross Bencina
I took a look at PaAlsaStreamComponent_DoChannelAdaption and yes, I
agree, the code appears to be zeroing the unused channels. Hard to say
whether using memset there is the most efficient option, but at least
they're zeroed. So Phil and my concern is addressed.

Fix now committed, r1954, so let's close this thread!

Regards

Alan

[Leif Asbrink]

Hello Alan,

The user has a Delta44. The hardware has 4 channels only,
putting some data into those 6 channels that will not be
used is meaningless.

Now, given the info that the device has 10 channels which probing
the device tells us, I could make the callback fill data
into the channels I want and zero in those I do not want.

Question: Would that improve performance compared to opening
the device for two channels or would it not make any difference?
My worry is latency, not cpu load.

Leif

Post by Alan Horstmann
This is 'a)', the user is outputting 1 or 2 channels to an Alsa device that
has 10 channels. The other 9 or 8 channels do seem to be filled with silence
OK. Bear in mind that when both channels and formats differ the adaption is
successfully happening this way at present. So for example in Audacity on
Linux the bug is masked with these soundcards (I believe) because it always
uses float32 internally.
Regards
Alan
_______________________________________________
Portaudio mailing list
http://music.columbia.edu/mailman/listinfo/portaudio

[Alan Horstmann]

This post might be inappropriate. Click to display it.

[Leif Asbrink]

Hi Alan,

Post by Alan Horstmann

Post by Leif Asbrink
Question: Would that improve performance compared to opening
the device for two channels or would it not make any difference?
My worry is latency, not cpu load.

I don't think that will make any difference to the latency in itself, since
latency is a consequence of the buffering scheme - eg if one chunk of data is
being played out while another is being filled by the application; there has
to be a delay of at least one chunk at the samplerate.

Sure - but I want to not have more:-)

Post by Alan Horstmann
Even if the CPU processing was limiting the minimum latency (rather than
scheduling uncertainties etc), it is not immediately clear to me which
approach would have the lower CPU usage and allow the smallest buffer size to
be used. Perhaps others would have more idea? Maybe tests/profiling would
be useful. The intention of Portaudio would be that you do not have to care
how many more channels the soundcard is capable of, and can just output those
wanted, so I would not advocate sending zero channels in these special cases.

Of course I do not want to get closer to the actual hardware than necessary.
It is essential to avoid resamplers, but format conversion might be fairly
harmless. I may make experiments on this some day, the issue is really,
will the callback I get in my application come directly from the hardware
in case I specify the format of the hardware while if a conversion is required
there would be an additional thread with a copy operation? On a modern platform
I do not think it would matter, but perhaps on a low level ARM??

Post by Alan Horstmann
What sort of latency values are you achieving, and how low would you usefully
like to go?

I set the latency factor to 1 and the buffer size to a fraction of a
millisecond. The delay through filters and other processes dominates.

The Linrad transceiver needs a delay from microphone to antenna and from
antenna back to the head phones that is below 100 ms. It is a bit difficult
to talk with a 100 ms delayed echo into ones ears, but it is not really
difficult. I would prefer to get the delay down to about 40 ms. Today
I can get 25 ms from antenna to ear-phones and 45 ms from microphone
to the antenna:

In total 70 ms. It would be nice to reduce that by a factor of two.

Windows is different. Extra buffers and delays are normally added.
Only ASIO seems to be OK, but very few hardware come with ASIO drivers,

Regards

Leif

[Leif Asbrink]

Hello All,

The problem is probably caused by alsa and not Portaudio.
The crasch gives this output:
pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0'
failed.
Aborted

There are messages (many) about missing configurations but they
are different on differen Debian versions. I have tested Wheezy,
Jessie and Sid.

The devices that fail are
front
surround 40
surround 41
surround 50
surround 51
surround 71

and maybe some more. It differs between the different Debian
versions. Ubuntu 12.04 as well as Ubuntu 14.04 have the same problem,
but Fedora 20 is OK. It reports 44100 t0 192000 as supported
sampling rates in Linrad. The Linrad log file from Debian
is like this:

TESTING PORTAUDIO DEVICE 11 FOR Rx output

id=11 device=front hostapi=ALSA max_input_chan=0 max_output_chan=6
Testing 0 8000.000000 err=-9997 Invalid sample rate
Testing 1 9600.000000 err=-9997 Invalid sample rate
Testing 2 11025.000000 err=-9997 Invalid sample rate
Testing 3 12000.000000 err=-9997 Invalid sample rate
Testing 4 16000.000000 err=-9997 Invalid sample rate
Testing 5 22050.000000 err=-9997 Invalid sample rate
Testing 6 24000.000000 err=-9997 Invalid sample rate
Testing 7 32000.000000 err=-9997 Invalid sample rate
Testing 8 44100.000000

This means that the call to Pa_IsFormatSupported does
not return when a supported rate is supplied.

Fedora 16 as well as Fedora 20 are OK. They list the device
capabilities properly. openSUSE 12.1 is also OK.

To me this seems to be a Debian problem with alsa. It occurs
only with Portaudio however. It is disturbing, users do not
like program crasches....

Leif

[Alan Horstmann]

Post by Leif Asbrink
The problem is probably caused by alsa and not Portaudio.
pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0'
failed.
Aborted
There are messages (many) about missing configurations but they
are different on differen Debian versions. I have tested Wheezy,
Jessie and Sid.
The devices that fail are
front
surround 40
surround 41
surround 50
surround 51
surround 71
and maybe some more. It differs between the different Debian
versions. Ubuntu 12.04 as well as Ubuntu 14.04 have the same problem,
but Fedora 20 is OK. It reports 44100 t0 192000 as supported
sampling rates in Linrad. The Linrad log file from Debian
TESTING PORTAUDIO DEVICE 11 FOR Rx output
id=11 device=front hostapi=ALSA max_input_chan=0 max_output_chan=6
Testing 0 8000.000000 err=-9997 Invalid sample rate
Testing 1 9600.000000 err=-9997 Invalid sample rate
Testing 2 11025.000000 err=-9997 Invalid sample rate
Testing 3 12000.000000 err=-9997 Invalid sample rate
Testing 4 16000.000000 err=-9997 Invalid sample rate
Testing 5 22050.000000 err=-9997 Invalid sample rate
Testing 6 24000.000000 err=-9997 Invalid sample rate
Testing 7 32000.000000 err=-9997 Invalid sample rate
Testing 8 44100.000000
This means that the call to Pa_IsFormatSupported does
not return when a supported rate is supplied.
Fedora 16 as well as Fedora 20 are OK. They list the device
capabilities properly. openSUSE 12.1 is also OK.
To me this seems to be a Debian problem with alsa. It occurs
only with Portaudio however. It is disturbing, users do not
like program crasches....

Indeed, they do not.

Bear in mind that asserts may be turned off in some distros - actually I
thought they were normally off, and only enabled for debug builds - so the
'working' distros may be only ignoring the issue.

Is this happening on any soundcard, or just (a) specific one(s)?

Let's focus on the most recent failing distro - Debian or Ubuntu, and give the
exact kernel version ('uname -a'). I'll try and get some response on the
Alsa-dev mailing list. I would have thought hitting an assert is always a
sign of an underlying bug.

Unfortunately, by their nature, once an assert is hit there is no way for the
function to continue and give an error return - it is 'game over'.

Regards

Alan

[Leif Asbrink]

Hello Alan,

Post by Alan Horstmann
Bear in mind that asserts may be turned off in some distros - actually I
thought they were normally off, and only enabled for debug builds - so the
'working' distros may be only ignoring the issue.

Hmmm, I do not know what asserts is....

Turning them off is fine with me, the problems occur only on devices
of no interest for SDR. (As far as I can understand.)

Post by Alan Horstmann
Is this happening on any soundcard, or just (a) specific one(s)?

I do not have the problem on my Pentium 4 machine. The problem
is with front, surround and hdmi. Presumably they belong to the
motherboard (Intel.)

At the moment I have a complex setup with two computers and a lot of
external hardware. At this time I do not want to disrupt everything
by de-installing soundcards. I am in the process of making a video
on speech processing to apply in front of a conventional transceiver.

Post by Alan Horstmann
Let's focus on the most recent failing distro - Debian or Ubuntu, and give the
exact kernel version ('uname -a'). I'll try and get some response on the
Alsa-dev mailing list. I would have thought hitting an assert is always a
sign of an underlying bug.

Well, All Debian and Ubuntu that are still maintained have this problem.
To specify a particular kernel: Debian 8 (jessie) 32 bit: 3.16.0-4-686-pae
It has the problem and it has ALSA version 1.0.28

Post by Alan Horstmann
Unfortunately, by their nature, once an assert is hit there is no way for the
function to continue and give an error return - it is 'game over'.

Seems to be a bad idea in a distribution. Better return "unknown error"
or something. The user has no chance in this case.

The work-around would be that I specify a list of devices and ask
the user which ones he wants to probe. He would then discover which
drivers cause a crasch and he could skip trying them. Elegant - NO:-(

Leif

[Alan Horstmann]

This post might be inappropriate. Click to display it.

[Alan Horstmann]

Hi Leif,

Post by Alan Horstmann
To track this down will require some further work. Firstly, more info on
http://www.alsa-project.org/alsa-info.sh
and run it (can use --no-upload option). It will gather the kind of info
Alsa-devels want. Do you have a custom asoundrc? Alongside the info, the
exact circumstances. Eg, does this occur on the front device with just a
single attempt at 44100, or is it only after several failed samplerates?
If your code starts with the high rate and works down, how do the results
change?

These last 2 tests will be valuable, please - try one rate, or several in a
different order, etc.

Post by Alan Horstmann
Ultimately a minimal test-case code that repeatedly demonstrates the issue
would be very valuable - perhaps a composite of bits of your code and small
bits of Portaudio_alsa - reduced by taking out anything that is not
necessary to show the problem. I suspect it is the actions done in the
pa_alsa function 'TestParameters()' that trigger this - indeed there is a
comment there about assertions being hit.

I've gone ahead and done much of the work here myself by creating a smallish
test program (approx 300 lines, just portaudio.h #include'd) that can be
compiled and run on it's own. I've attached test_format.c; copy standard
portaudio.h into the same directory.

The test format, channels and rates to be tested (an array of sequential
values) are all set with defines. If we can mimic the exact circumstances
that cause the assert, and reproduce it, we have a crude minimal demo
program. All the functions are copied from pa_linux_alsa.c, with quick
changes to minimise includes and unnecessary functions.

Here is example output:

./test-format
Testing rate: 22050
AlsaOpen: Opening device front
Result:....Success!!!
Testing rate: 32000
AlsaOpen: Opening device front
Result:....Success!!!
Testing rate: 44100
AlsaOpen: Opening device front
Result:....Success!!!
Testing rate: 48000
AlsaOpen: Opening device front
Result:....Success!!!
Testing rate: 96000
AlsaOpen: Opening device front
Result:....Invalid Sample Rate

I think you were using 6 channel output to 'front', Int16? It would be great
if you cold compile and run this, with the correct parameters and rates, and
hopefully be able to reproduce the assert somehow?


Regards

Alan

[Leif Asbrink]

Hi Alan,

Post by Alan Horstmann
The Delta44 is based on the 'envy24' chipset, I believe, as the Delta1010,
DMX6fire and others; I have 2 such. I am fairly sure I have captured in
32-bit successfully at some time in the past (using Linux, Audacity).

Input with 32 bit works fine. The problem is with the output only.

Post by Alan Horstmann
It may be relevant or not that the envy24 ALWAYS transfers a fixed data
format/channels at the hardware level. There are always 10 playback and 12
capture channels, of 24-bit samples (LE) packed into 32-bits. I know this
causes problems on Linux using raw ALSA (not Portaudio) as it is not possible
to write 2 channels to the hardware (hw:n) devices. ASIO is also a low-level
driver is it not? So Portaudio should be doing channel adaption. There is
also possibly confusion over the data number of bits.

This might explain where the factor 10 comes from. Interestingly enough
ALSA works correctly which means that Portaudio must interface to
ALSA at a lower level than the normal API that I am using. Also
/dev/dsp2 with alsa-oss works fine with 32 bit output.

ASIO is a low level API with very low latency. Other drivers under
Windows insert extra buffers and cause unacceptable delay in the order
of 50 to 120 ms. There are other fast drivers, WASAPI or WDM-KS but
they are not as fast as ASIO.

Post by Alan Horstmann
It should be fairly straightforward to narrow down the issue, hopefully!

I hope so:-)

Regards

Leif

[Alan Horstmann]

Hi Leif,

Post by Alan Horstmann

Post by Alan Horstmann
To track this down will require some further work. Firstly, more info
http://www.alsa-project.org/alsa-info.sh

My reply was stopped "Message body is too big: 87014 bytes
with a limit of 20 KB" The output from
http://www.alsa-project.org/alsa-info.sh
was too big.

Ah, OK. Maybe try the upload option - it will put it somewhere and give the
link, I think?

Post by Alan Horstmann
Do you have a custom asoundrc?

No.

Post by Alan Horstmann
Alongside the info, the
exact circumstances. Eg, does this occur on the front device with just a
single attempt at 44100,

Yes.

Post by Alan Horstmann
Ultimately a minimal test-case code that repeatedly demonstrates the
issue would be very valuable - perhaps a composite of bits of your code
and small bits of Portaudio_alsa - reduced by taking out anything that is
not necessary to show the problem.

OK. Here is a test program of less than 100 lines that demonstrates the

Thanks, that is useful. <sniped>

Look at the code. Half of it is overhead, this little program aborts
every time - even if I change the order in which speeds are probed.

Post by Alan Horstmann

Post by Alan Horstmann
Ultimately a minimal test-case code that repeatedly demonstrates the
issue would be very valuable - perhaps a composite of bits of your code
and small bits of Portaudio_alsa - reduced by taking out anything that
is not necessary to show the problem. I suspect it is the actions done
in the pa_alsa function 'TestParameters()' that trigger this - indeed
there is a comment there about assertions being hit.

Well, I did that - plus the alsa-info.sh but did not make it through the
moderator.

Yes, OK, that has caused me problems as well. It is surprising sometimes how
little can be posted - even portaudio.h is twice over the limit. But I
suppose given all the list archiving, it is reasonable to have quite a low
limit.

Post by Alan Horstmann
I've gone ahead and done much of the work here myself by creating a
smallish test program (approx 300 lines, plus just portaudio.h) that can
be compiled and run on it's own. I've attached a zip of test_format.c
with portaudio.h. The test format, channels and rates to be tested (an
array of sequential values) are all set with defines. If we can mimic
the exact circumstances that cause the assert, and reproduce it, we have
a crude minimal demo program. All the functions are copied from
pa_linux_alsa.c, with quick changes to minimise includes and unnecessary
functions.

Testing rate: 22050
AlsaOpen: Opening device front
Result:....Invalid Sample Rate
Testing rate: 32000
AlsaOpen: Opening device front
Result:....Invalid Sample Rate
Testing rate: 44100
AlsaOpen: Opening device front
Result:....Success!!!
Testing rate: 48000
AlsaOpen: Opening device front
Result:....Success!!!
Testing rate: 96000
AlsaOpen: Opening device front
Result:....Success!!!

Interesting. Did you try changing the num channels up to 6, as I can see that
is what your test program will be using, as it takes the max device channels?

Post by Alan Horstmann
I think you were using 6 channel output to 'front', Int16? It would be
great if you cold compile and run this, with the correct parameters and
rates, and hopefully be able to reproduce the assert somehow?

The very small program I wrote and again send to the list reproduces the
assert every time. You can see in the code exactly what I did. I also tried
to limit the number of channels to 4 in the case Portaudio would report
more, but that made no difference. The purpose of the excercise is to make
sure that no resampler will be invoked.

Perhaps try 2 channels here, also?

Regards

Alan

[Alan Horstmann]

Hi Leif,

On Sunday 26 April 2015 23:07, you wrote:
On Saturday 25 April 2015 22:18, Alan Horstmann wrote:
< re alsa-info.sh >

Post by Alan Horstmann
Ah, OK. Maybe try the upload option - it will put it somewhere and give
the link, I think?

Hmmm, the VERY small test program I wrote crasches every time. On two
different computers. As far as I can understand I am not doing anything
unacceptable with the code (???)

The assert is in Alsa-lib; at this stage we're trying to narrow down what
causes it, but I do suspect it is not in your code. The Alsa-info will be
important to take the issue to the Alsa-devel list.

Post by Alan Horstmann

Post by Alan Horstmann
I've gone ahead and done much of the work here myself by creating a
smallish test program

Interesting. Did you try changing the num channels up to 6, as I can see
that is what your test program will be using, as it takes the max device
channels?

No, but I changed my test program to never test more than 4 channels
and that mafe no difference.

I think we need results for 2, 4, 6 channels with *both* test programs,
otherwise they cannot be compared. It may be that only stereo is working
with 'front'? The 2 test programs should produce the same result; if not, we
need to investigate the difference as it may be significant.

Did you try my little test program under Debian? (Probably needs
an Intel soundcard to crasch.)

Unfortunately I have not had any Debian installation. I am looking at doing
so if necessary. (BTW, in English the spelling is 'crash'.)

Regards

Alan

[Leif Asbrink]

Hi Alan,

Post by Alan Horstmann
The assert is in Alsa-lib; at this stage we're trying to narrow down what
causes it, but I do suspect it is not in your code. The Alsa-info will be
important to take the issue to the Alsa-devel list.

Hmmm, did you look at my code? I attach a stripped version of 64 lines
only that repeatedly causes a crash on all Debian systems..

Post by Alan Horstmann

Post by Alan Horstmann

Post by Alan Horstmann
I've gone ahead and done much of the work here myself by creating a
smallish test program

Interesting. Did you try changing the num channels up to 6, as I can see
that is what your test program will be using, as it takes the max device
channels?

No, but I changed my test program to never test more than 4 channels
and that mafe no difference.

I think we need results for 2, 4, 6 channels with *both* test programs,
otherwise they cannot be compared. It may be that only stereo is working
with 'front'? The 2 test programs should produce the same result; if not, we
need to investigate the difference as it may be significant.

NO!! Your test program does not call Pa_IsFormatSupported so it does
not crash. Please look at my few lines of code to see if something
I have done is not legal.

I have Portaudio from source so I have traced the call to Pa_IsFormatSupported
and as it turns out, the problem is near line 1796 in pa_linux_alsa.c

if( ( ret = alsa_snd_pcm_hw_params( pcm, hwParams ) ) < 0 )

the call to alsa_snd_pcm_hw_params does not return, instead the assert error
is produced when 'front' or the other offending devices are probed with
a valid sample rate under Debian.

When I change outputParameters.sampleFormat from paInt16 to paInt24 the
error disappears.

Regards

Leif

[Alan Horstmann]

Hi Leif,

Post by Leif Asbrink

Post by Alan Horstmann
The assert is in Alsa-lib; at this stage we're trying to narrow down what
causes it, but I do suspect it is not in your code. The Alsa-info will
be important to take the issue to the Alsa-devel list.

Hmmm, did you look at my code? I attach a stripped version of 64 lines
only that repeatedly causes a crash on all Debian systems..

Yeah, but the demo only makes Alsa-info more necessary - to show the hardware
and Alsa configuration info etc. Won't get far on Alsa-devel list without
it. I am trying to help you get a resolution to this issue.

Post by Leif Asbrink

Post by Alan Horstmann

Post by Alan Horstmann

Post by Alan Horstmann
I've gone ahead and done much of the work here myself by creating
a smallish test program

Interesting. Did you try changing the num channels up to 6, as I can
see that is what your test program will be using, as it takes the max
device channels?

No, but I changed my test program to never test more than 4 channels
and that mafe no difference.

I think we need results for 2, 4, 6 channels with *both* test programs,
otherwise they cannot be compared. It may be that only stereo is working
with 'front'? The 2 test programs should produce the same result; if
not, we need to investigate the difference as it may be significant.

NO!! Your test program does not call Pa_IsFormatSupported so it does
not crash. Please look at my few lines of code to see if something
I have done is not legal.

Yes!! My test program *IS* the content of Pa_IsFormatSupported() stripped
back further, so that there is no dependency on any external library or code
(apart from Portaudio.h itself). It should build standalone and fail in
exactly the same way. The troublesome elements have to be distilled as far
as possible down to the absolute minimum explicit code so the issue can be
shown to others. If it does not show the fault, code will have to be added
back in until it does fail. Then we know the trigger.

Post by Leif Asbrink
I have Portaudio from source so I have traced the call to
Pa_IsFormatSupported and as it turns out, the problem is near line 1796 in
pa_linux_alsa.c
if( ( ret = alsa_snd_pcm_hw_params( pcm, hwParams ) ) < 0 )
the call to alsa_snd_pcm_hw_params does not return, instead the assert
error is produced when 'front' or the other offending devices are probed
with a valid sample rate under Debian.

That line is when the same call is in the test code I put together, L271 (the
'alsa_' in the 'Pa_IsFormatSupported()' version is just a wrapper mechanism).
So I expect it to demonstrate the same assert given the same conditions - ie
4 or 6 channels rather than the 2 defined initially. That is why I need
those results - 2, 4, 6 channels - from both test programs.

Post by Leif Asbrink
When I change outputParameters.sampleFormat from paInt16 to paInt24 the
error disappears.

OK, that is an interesting factor; does the paInt24 case result in the format
supported, or not supported?

Regards

Alan

[Leif Asbrink]

Hi Alan,

Post by Alan Horstmann
Yeah, but the demo only makes Alsa-info more necessary - to show the hardware
and Alsa configuration info etc. Won't get far on Alsa-devel list without
it. I am trying to help you get a resolution to this issue.

Fine. I tried the upload option and here is the link:
http://www.alsa-project.org/db/?f=19dfeee29f73007e61a00a8fabe3c958f7cb8e87

Post by Alan Horstmann
Yes!! My test program *IS* the content of Pa_IsFormatSupported() stripped
back further, so that there is no dependency on any external library or code
(apart from Portaudio.h itself). It should build standalone and fail in
exactly the same way. The troublesome elements have to be distilled as far
as possible down to the absolute minimum explicit code so the issue can be
shown to others. If it does not show the fault, code will have to be added
back in until it does fail. Then we know the trigger.

Well, something differs - but I am sure it can be sorted out.
The abort I see must happen if portaudio is stripped from everything
not needed...

Post by Alan Horstmann

Post by Leif Asbrink
I have Portaudio from source so I have traced the call to
Pa_IsFormatSupported and as it turns out, the problem is near line 1796 in
pa_linux_alsa.c
if( ( ret = alsa_snd_pcm_hw_params( pcm, hwParams ) ) < 0 )
the call to alsa_snd_pcm_hw_params does not return, instead the assert
error is produced when 'front' or the other offending devices are probed
with a valid sample rate under Debian.

That line is when the same call is in the test code I put together, L271 (the
'alsa_' in the 'Pa_IsFormatSupported()' version is just a wrapper mechanism).
So I expect it to demonstrate the same assert given the same conditions - ie
4 or 6 channels rather than the 2 defined initially. That is why I need
those results - 2, 4, 6 channels - from both test programs.

With my program front succeds when I set 4 channels but
2 or 6 channels fail, but the next, surround21, fails with an abort.

With your test program, 2 and 4 channels is OK, but when I set 6 channels
I get this result:
***@Xeon:/home/patest# ./test-format
Testing rate: 22050
AlsaOpen: Opening device front
Result:....Invalid Sample Rate
Testing rate: 32000
AlsaOpen: Opening device front
Result:....Invalid Sample Rate
Testing rate: 44100
AlsaOpen: Opening device front
test-format: pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0
Aborted

Post by Alan Horstmann

Post by Leif Asbrink
When I change outputParameters.sampleFormat from paInt16 to paInt24 the
error disappears.

OK, that is an interesting factor; does the paInt24 case result in the format
supported, or not supported?

paInt24 gives format is supported.

Regards

Leif

[Alan Horstmann]

Hi Leif,

Post by Leif Asbrink
http://www.alsa-project.org/db/?f=19dfeee29f73007e61a00a8fabe3c958f7cb8e87

Looks great.

Post by Leif Asbrink
With my program front succeds when I set 4 channels but
2 or 6 channels fail, but the next, surround21, fails with an abort.
With your test program, 2 and 4 channels is OK, but when I set 6 channels
Testing rate: 22050
AlsaOpen: Opening device front
Result:....Invalid Sample Rate
Testing rate: 32000
AlsaOpen: Opening device front
Result:....Invalid Sample Rate
Testing rate: 44100
AlsaOpen: Opening device front
test-format: pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >=
0 Aborted

Post by Alan Horstmann

Post by Leif Asbrink
When I change outputParameters.sampleFormat from paInt16 to paInt24 the
error disappears.

OK, that is an interesting factor; does the paInt24 case result in the
format supported, or not supported?

paInt24 gives format is supported.

Just a couple more things. I've further stripped down the test-format program
to remove the need for portaudio.h (huge file), fixed one bug and changed the
output a little. I would be grateful if you could run this version, check
the assert occurs and post the output. Could also change to surround51. I
will then put this to the Alsa-devel list, with the alsa-info link.

Also, I realised I had omitted to mention 'Pulseaudio', which is probably part
of the cause. So try running the troublesome programs after
'pasuspender' (you may need web search to get the exact details).

Regards

Alan

[Leif Asbrink]

Hi Alan,

Post by Alan Horstmann
Just a couple more things. I've further stripped down the test-format program
to remove the need for portaudio.h (huge file), fixed one bug and changed the
output a little. I would be grateful if you could run this version, check
the assert occurs and post the output.

Here is the output:
***@Xeon:/home/patest# ./test-format
Testing device front
Num channels 6
Testing rate: 22050 Result:...Invalid Sample Rate
Testing rate: 32000 Result:...Invalid Sample Rate
test-format: pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >=
0' failed.
Testing rate: 44100 Aborted

Post by Alan Horstmann
Also, I realised I had omitted to mention 'Pulseaudio', which is probably part
of the cause. So try running the troublesome programs after
'pasuspender' (you may need web search to get the exact details).

pasuspender ./test-format
Connection failure: Connection refused
pa_context_connect() failed: Invalid argument
***@Xeon:/home/patest#

Presumably this is because pulseaudio was not started.
I have now enabled pulseaudio and I find that the output from test-format is
the same regardless of whether I run with pasuspender or not.

Your new test-format that always fails should make it fairly easy for
alsa developers to reproduce the problem:-)

Regards

Leif

Post by Alan Horstmann
Regards
Alan

[Alan Horstmann]

Hi Leif,

I am aware it has gone quiet on this issue. There has been no response to the
info on Alsa-devel, probably not helped as the most useful person is/has been
on vacation.

Post by Leif Asbrink
Testing device front
Num channels 6
Testing rate: 22050 Result:...Invalid Sample Rate
Testing rate: 32000 Result:...Invalid Sample Rate
test-format: pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >=
0' failed.
Testing rate: 44100 Aborted

<snip>

Post by Leif Asbrink
Your new test-format that always fails should make it fairly easy for
alsa developers to reproduce the problem:-)

I wonder if it would be worth you reporting it as a Debian (or Ubuntu) bug,
and see if others can reproduce the assert? Then that might give more
traction on Alsa-devel.

However, first one long-shot: the order of setting rate, channels, format
varies in the pa-linux-alsa code, and is not the same as used in Alsa
examples. So I have switched it round in the test-format-fcr program
attached, from 'r-c-f' to 'f-c-r'. Can you try that and see if it makes any
difference to the results?

Regards

Alan

[Leif Asbrink]

Hello Alan,

Post by Alan Horstmann
I wonder if it would be worth you reporting it as a Debian (or Ubuntu) bug,
and see if others can reproduce the assert? Then that might give more
traction on Alsa-devel.

That seems to be a good idea. I have tested all the Linux distributions
that I have installed on the machine.

Fedora, SuSE and Mageia are OK. They seem to ignore asserts(??)
Debian (jessie), Ubuntu, PCLinuxOS and Sabayon have problems.
See attached files. They are all with test_format_fcr.c

Post by Alan Horstmann
However, first one long-shot: the order of setting rate, channels, format
varies in the pa-linux-alsa code, and is not the same as used in Alsa
examples. So I have switched it round in the test-format-fcr program
attached, from 'r-c-f' to 'f-c-r'. Can you try that and see if it makes any
difference to the results?

As you can see it makes no difference.

I have not verified that the devices work properly in Fedora, SuSE and Mageia
but to me it does not matter. These devices are of no interest in an SDR
context (as far as I understand) I just do not want my program to crash
when probing all devices.

Regards

Leif

[Alan Horstmann]

Hi Leif,

Post by Alan Horstmann
I am aware it has gone quiet on this issue. There has been no response to
the info on Alsa-devel, probably not helped as the most useful person
is/has been on vacation.

Now he is back from vacation, I have been requested that we check if the
following patch 'fixes' the issue, although as you will see all it is doing
is converting the assert into an err return. The crash is then avoided.

Are you able to build the Alsa-lib package from source? I am not familiar
with the process; but this seemed to cover it:
https://www.debian-administration.org/article/20/Rebuilding_Debian_packages
Check it still fails with the compiled package, then apply the patch and check
again.

I am not sure whether the format/chans/rate that caused the assert should be
usable or not on your system?

Regards

Alan

diff --git a/src/pcm/pcm_params.c b/src/pcm/pcm_params.c
index 6e57904e445b..1d667a583151 100644
--- a/src/pcm/pcm_params.c
+++ b/src/pcm/pcm_params.c
@@ -2244,9 +2244,11 @@ int snd_pcm_hw_params_slave(snd_pcm_t *pcm,
snd_pcm_hw_params_t *params,
        snd_pcm_hw_params_t slave_params;
        int err;
        err = sprepare(pcm, &slave_params);
-       assert(err >= 0);
+       if (err < 0)
+               return err;
        err = schange(pcm, params, &slave_params);
-       assert(err >= 0);
+       if (err < 0)
+               return err;
        err = sparams(pcm, &slave_params);
        if (err < 0)
                cchange(pcm, params, &slave_params);

[Leif Asbrink]

Hello Alan,

Very good!!

This patch solves my problem:-)

I get devices and I can open the front device. It does not
work well, far too slow with glitches. The motherboard
device is no longer present, the new libasound.so.2.0.0
is not compatible with the rest of my Debian Sid 64
installation so I do not worry about things not working
properly with my new lib. I could not find out how to
compile from source within Debian so I fetched the source
from alsa-project.org

The assert errors are gone as expected and this patch will not
cause problems on devices which work with the current Debian package.
I have confirmed that I do get the assert abort when I compile
without the patch.

Do you have any idea what time it might take until this patch
reaches the Debian and Ubuntu repos?

Regards

Leif

Post by Alan Horstmann
Hi Leif,

Post by Alan Horstmann
I am aware it has gone quiet on this issue. There has been no response to
the info on Alsa-devel, probably not helped as the most useful person
is/has been on vacation.

Now he is back from vacation, I have been requested that we check if the
following patch 'fixes' the issue, although as you will see all it is doing
is converting the assert into an err return. The crash is then avoided.
Are you able to build the Alsa-lib package from source? I am not familiar
https://www.debian-administration.org/article/20/Rebuilding_Debian_packages
Check it still fails with the compiled package, then apply the patch and check
again.
I am not sure whether the format/chans/rate that caused the assert should be
usable or not on your system?
Regards
Alan
diff --git a/src/pcm/pcm_params.c b/src/pcm/pcm_params.c
index 6e57904e445b..1d667a583151 100644
--- a/src/pcm/pcm_params.c
+++ b/src/pcm/pcm_params.c
@@ -2244,9 +2244,11 @@ int snd_pcm_hw_params_slave(snd_pcm_t *pcm,
snd_pcm_hw_params_t *params,
        snd_pcm_hw_params_t slave_params;
        int err;
        err = sprepare(pcm, &slave_params);
-       assert(err >= 0);
+       if (err < 0)
+               return err;
        err = schange(pcm, params, &slave_params);
-       assert(err >= 0);
+       if (err < 0)
+               return err;
        err = sparams(pcm, &slave_params);
        if (err < 0)
                cchange(pcm, params, &slave_params);
_______________________________________________
Portaudio mailing list
http://music.columbia.edu/mailman/listinfo/portaudio

[Alan Horstmann]

Post by Leif Asbrink
Hello Alan,
Very good!!
This patch solves my problem:-)
I get devices and I can open the front device. It does not
work well, far too slow with glitches. The motherboard
device is no longer present, the new libasound.so.2.0.0
is not compatible with the rest of my Debian Sid 64
installation so I do not worry about things not working
properly with my new lib. I could not find out how to
compile from source within Debian so I fetched the source
from alsa-project.org
The assert errors are gone as expected and this patch will not
cause problems on devices which work with the current Debian package.
I have confirmed that I do get the assert abort when I compile
without the patch.
Do you have any idea what time it might take until this patch
reaches the Debian and Ubuntu repos?

See

http://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=67f73b0fab466e780dcc0442e19894a1cbedc43b

so it will be in the next Alsa-lib release; but I've no idea when that gets
picked up by the distros, or if it gets backported. The configuration
failure is clearly an issue fairly specific to the particular hardware you
have, others have not been able to reproduce. But the assert should not have
been there!

One additional thing, the file 'pcm_params.c' can be compiled with RULES_DEBUG
defined - see around line 2000 to enable it. This would give more info as to
what way the particular config fails in your specific case.

Regards

Alan

[Leif Asbrink]

Hello Alan,

Post by Alan Horstmann

Post by Leif Asbrink
Do you have any idea what time it might take until this patch
reaches the Debian and Ubuntu repos?

See
http://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=67f73b0fab466e780dcc0442e19894a1cbedc43b
so it will be in the next Alsa-lib release; but I've no idea when that gets
picked up by the distros, or if it gets backported. The configuration
failure is clearly an issue fairly specific to the particular hardware you
have, others have not been able to reproduce. But the assert should not have
been there!

OK. I actually have two different computers that crash on the assert.
One is an Intel D5400XS and the other a Supermicro X9Dai. Both use the
intel module snd_hda_intel.

Post by Alan Horstmann
One additional thing, the file 'pcm_params.c' can be compiled with RULES_DEBUG
defined - see around line 2000 to enable it. This would give more info as to
what way the particular config fails in your specific case.

The config actually does not fail(??). Portaudio reports that it is OK
but that the only supported speed is 44100 Hz.

I can not really test it because the whole sound system is corrupted since
I do not know how to compile alsa for Debian properly. The device works, but with
glitches.

Under Fedora it is different. The front device reports 44100 to 192000 Hz
and it works perfectly well. I was able to compile from source properly
and I replaced the assert(err>=0); with this:

if(err < 0)
{
fprintf(stderr,"assert error");
abort();
}

This has no effect, in Fedore there is no error!!!

I verified by this statement:
if(err >= 0)
{
fprintf(stderr,"assert error");
abort();
}

that I really execute the library I compiled. I do get an abort immediately.

Conclusion: Something is wrong in Debian. The replacement of assert with return
will hide the error and that is perfectly OK for my project. Since I have the problem
on two computers of different generations it should not be difficult to
reproduce for Debian developers. Maybe the bug has some more serious effects??

Regards

Leif