Assert in pcm_params.c

Assert in pcm_params.c

[Alan Horstmann]

Hi,

The following assert is being hit in pcm_params.c:

"pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0' failed."

This is from a developer using Portaudio in his own application; I have yet to 
ascertain full details, but it is trying successive sample rates to see which 
are valid.

Does this point to a flaw in the configuration or possibly a bug in Alsa-lib 
or can it occur just as a result of misuse of the Alsa API?

Regards

Alan

Re: Assert in pcm_params.c

[Raymond Yau]

>
> Hi,
>
> The following assert is being hit in pcm_params.c:
>
> "pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0'
failed."
>
> This is from a developer using Portaudio in his own application; I have
yet to
> ascertain full details, but it is trying successive sample rates to see
which
> are valid.
>
> Does this point to a flaw in the configuration or possibly a bug in
Alsa-lib
> or can it occur just as a result of misuse of the Alsa API?
>
>

http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.html

Only snd_pcm_hw_params_test_rate() can be call multiple times,
Verify if a rate is available inside a configuration space for a PCM.

Those snd_pcm_hw_params_ser_rate*  functions restrict the configuration
space to one rate and can be called once only

Re: Assert in pcm_params.c

[Alan Horstmann]

On Saturday 18 April 2015 09:54, Raymond Yau wrote:
> > Hi,
> >
> > The following assert is being hit in pcm_params.c:
> >
> > "pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0'>
> > failed."
>
> > This is from a developer using Portaudio in his own application; I have
> > yet to ascertain full details, but it is trying successive sample rates to 
> > see which are valid.
> >
> > Does this point to a flaw in the configuration or possibly a bug in
> > Alsa-lib or can it occur just as a result of misuse of the Alsa API?
>
> http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.
>html
>
> Only snd_pcm_hw_params_test_rate() can be call multiple times,
> Verify if a rate is available inside a configuration space for a PCM.
>
> Those snd_pcm_hw_params_ser_rate*  functions restrict the configuration
> space to one rate and can be called once only

The stream is being opened and closed at each attempt.

Regards

Alan

Re: Assert in pcm_params.c

[Raymond Yau]

> > > Hi,
> > >
> > > The following assert is being hit in pcm_params.c:
> > >
> > > "pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0'>
> > > failed."
> >
> > > This is from a developer using Portaudio in his own application; I
have
> > > yet to ascertain full details, but it is trying successive sample
rates to
> > > see which are valid.
> > >
> > > Does this point to a flaw in the configuration or possibly a bug in
> > > Alsa-lib or can it occur just as a result of misuse of the Alsa API?

> >
> >
http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.
> >html
> >
> > Only snd_pcm_hw_params_test_rate() can be call multiple times,
> > Verify if a rate is available inside a configuration space for a PCM.
> >
> > Those snd_pcm_hw_params_ser_rate*  functions restrict the configuration
> > space to one rate and can be called once only
>
> The stream is being opened and closed at each attempt.

Seem Delta 44 does not support 2,4,6 or 8 channels

aplay --dump-hw-params -Dhw:CARD=M44 any.wav

Do both channel min and channel max > 8 ?

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/pci/ice1712/delta.c

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/pci/ice1712/ice1712.c

rates = SNDRV_PCM_RATE_CONTINUOUS | SNDRV_PCM_RATE_8000_48000,
.rate_min = 4000,
.rate_max = 48000,

If the driver really support any rate between 4000Hz and 48000Hz, the list
of supported rates has 48000-4000+1 entries

Re: Assert in pcm_params.c

[Alan Horstmann]

On Saturday 18 April 2015 09:08, I wrote:
> The following assert is being hit in pcm_params.c:
>
> "pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0' failed."
>
> This is from a developer using Portaudio in his own application; I have yet
> to ascertain full details, but it is trying successive sample rates to see
> which are valid.

Further info: this occurs with an Intel motherboard/soundcard, attempting to 
open and config the stream at 44100 using front, surround or hdmi pcm, having 
previously opened and tried at a lower, not-supported samplerate, and closed.
AFAIK other pcms work OK.

The assert is hit with all current Debian and Ubuntu distros, for example
     Debian 8 (jessie) 32 bit:  kernel 3.16.0-4-686-pae (Alsa 1.0.28)
but is not seen with Fedora 20 or OpenSuse 12.1 (do they have asserts off?).

> Does this point to a flaw in the configuration or possibly a bug in
> Alsa-lib or can it occur just as a result of misuse of the Alsa API?

I will try to conceive some more tests.  How can we debug this further?

Regards

Alan

Re: Assert in pcm_params.c

[Alan Horstmann]

On Monday 20 April 2015 08:08, you wrote:
> > > > Hi,
> > > >
> > > > The following assert is being hit in pcm_params.c:
> > > >
> > > > "pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0'>
> > > > failed."
> > > >
> > > > This is from a developer using Portaudio in his own application; I
<snip>
> > > > Does this point to a flaw in the configuration or possibly a bug in
> > > > Alsa-lib or can it occur just as a result of misuse of the Alsa API?
>
> http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.
> > >
> > > Only snd_pcm_hw_params_test_rate() can be call multiple times,
> > > Verify if a rate is available inside a configuration space for a PCM.
> > >
> > > Those snd_pcm_hw_params_ser_rate*  functions restrict the configuration
> > > space to one rate and can be called once only
> >
> > The stream is being opened and closed at each attempt.
>
> Seem Delta 44 does not support 2,4,6 or 8 channels

This issue is not on Delta44, but an Intel motherboard.  But I would not 
expect to hit an assert in Alsa-lib whatever we do, surely?

Regards

Alan

Re: Assert in pcm_params.c

[Raymond Yau]

> > The following assert is being hit in pcm_params.c:
> >
> > "pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0'
failed."
> >
> > This is from a developer using Portaudio in his own application; I have
yet
> > to ascertain full details, but it is trying successive sample rates to
see
> > which are valid.
>
> Further info: this occurs with an Intel motherboard/soundcard, attempting
to
> open and config the stream at 44100 using front, surround or hdmi pcm,
having
> previously opened and tried at a lower, not-supported samplerate, and
closed.
> AFAIK other pcms work

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:
root <at> 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

Most likely bug in those user defined devices

Do portaudio hardcode "rear" device ?

http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/conf/cards/HDA-Intel.conf;hb=HEAD

Not all hda codecs support 44100Hz

Which hda codec?

>
> The assert is hit with all current Debian and Ubuntu distros, for example
>      Debian 8 (jessie) 32 bit:  kernel 3.16.0-4-686-pae (Alsa 1.0.28)
> but is not seen with Fedora 20 or OpenSuse 12.1 (do they have asserts
off?).
>
> > Does this point to a flaw in the configuration or possibly a bug in
> > Alsa-lib or can it occur just as a result of misuse of the Alsa API?
>
> I will try to conceive some more tests.  How can we debug this further
> Regards
>
>

Output of alsa-info.sh

and those customised devices in asoundrc

Re: Assert in pcm_params.c

[Raymond Yau]

> > > > > Hi,
> > > > >
> > > > > The following assert is being hit in pcm_params.c:
> > > > >
> > > > > "pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >=
0'>
> > > > > failed."
> > > > >
> > > > > This is from a developer using Portaudio in his own application; I
> <snip>
> > > > > Does this point to a flaw in the configuration or possibly a bug
in
> > > > > Alsa-lib or can it occur just as a result of misuse of the Alsa
API?
> >
> >
http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.
> > > >
> > > > Only snd_pcm_hw_params_test_rate() can be call multiple times,
> > > > Verify if a rate is available inside a configuration space for a
PCM.
> > > >
> > > > Those snd_pcm_hw_params_ser_rate*  functions restrict the
configuration
> > > > space to one rate and can be called once only
> > >
> > > The stream is being opened and closed at each attempt.
> >
> > Seem Delta 44 does not support 2,4,6 or 8 channels
>
> This issue is not on Delta44, but an Intel motherboard.  But I would not
> expect to hit an assert in Alsa-lib whatever we do, surely?

> 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

9600,12000 are not in Table 56. Defined Sample Rates of HDA specification

http://git.kernel.org/cgit/linux/kernel/git/tiwai/hda-emu.git/tree/codecs/ad1988b-asus-p5b-deluxe-wifi?id=HEAD

Most 6 channels audio are at 48000Hz, but some application upmix stereo
44100Hz to 6 channels

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda?id=5f1545bc45a33361d6bb2fb44af7c35bcd733b9d

>From the HDA spec it appears that the buffers written to the BDL and
sent to a codec must be 128 byte aligned (section 4.5.1).  The alignment
was not happening especially when playing 6 channels.

Do you mean the driver still have this alignment when playing 6 channel ?
I

Re: Assert in pcm_params.c

[Alan Horstmann]

[-- Attachment #1: Type: text/plain, Size: 2143 bytes --]

On Monday 20 April 2015 12:17, Alan Horstmann wrote:
> On Saturday 18 April 2015 09:08, Alan Horstmann wrote:
> > The following assert is being hit in pcm_params.c:
> >
> > "pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0'
> > failed."
> >
> > This is from a developer using Portaudio in his own application; I have
> > yet to ascertain full details, but it is trying successive sample rates
> > to see which are valid.
>
> Further info: this occurs with an Intel motherboard/soundcard, attempting
> to open and config the stream at 44100 using front, surround or hdmi pcm,
> having previously opened and tried at a lower, not-supported samplerate,
> and closed. AFAIK other pcms work OK.
>
> The assert is hit with all current Debian and Ubuntu distros, for example
>      Debian 8 (jessie) 32 bit:  kernel 3.16.0-4-686-pae (Alsa 1.0.28)
> but is not seen with Fedora 20 or OpenSuse 12.1 (do they have asserts
> off?).
>
> > Does this point to a flaw in the configuration or possibly a bug in
> > Alsa-lib or can it occur just as a result of misuse of the Alsa API?
>
> I will try to conceive some more tests.  How can we debug this further?

A minimal self-contained demo program ('test-format') has been developed and 
is attached, that demonstrates the issue 100% on the reporters machine 
(HDA-Intel, 6-ch I believe).  The output is:

root@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

Alsa-info is at:

http://www.alsa-project.org/db/?f=19dfeee29f73007e61a00a8fabe3c958f7cb8e87

This apparently happens with or without Pulseaudio running, with just the 
single 44100 rate, and also with surround devices.  Also, on all current 
Debian and Ubuntu - we have focused on Jessie.

I do not have a machine with similar hardware, so cannot duplicate the 
results.

Any comments, ideas etc would be appreciated.

Regards

Alan

[-- Attachment #2: test_format.c --]
[-- Type: text/x-csrc, Size: 9318 bytes --]

/*
 * test_format.c
 *
 * A minimal Alsa-Linux parameter test program derived crudely from Portaudio source code
 *
 * Compile from the command-line:  'gcc -Wall -Wextra -o test-format test_format.c -lasound'
 *
 * Alan Horstmann  30th April 2015
 */

/*
 * PortAudio Portable Real-Time Audio Library
 * Latest Version at: http://www.portaudio.com
 * ALSA implementation by Joshua Haberman and Arve Knudsen
 *
 * Copyright (c) 2002 Joshua Haberman <joshua@haberman.com>
 * Copyright (c) 2005-2009 Arve Knudsen <arve.knudsen@gmail.com>
 * Copyright (c) 2008 Kevin Kofler <kevin.kofler@chello.at>
 * Copyright (c) 2014-2015 Alan Horstmann <gineera@aspect135.co.uk>
 *
 * Based on the Open Source API proposed by Ross Bencina
 * Copyright (c) 1999-2002 Ross Bencina, Phil Burk
 *
 * Permission is hereby granted, free of charge, to any person obtaining
 * a copy of this software and associated documentation files
 * (the "Software"), to deal in the Software without restriction,
 * including without limitation the rights to use, copy, modify, merge,
 * publish, distribute, sublicense, and/or sell copies of the Software,
 * and to permit persons to whom the Software is furnished to do so,
 * subject to the following conditions:
 *
 * The above copyright notice and this permission notice shall be
 * included in all copies or substantial portions of the Software.
 *
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
 * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
 * IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR
 * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
 * CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
 * WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 */


#define ALSA_PCM_NEW_HW_PARAMS_API
#define ALSA_PCM_NEW_SW_PARAMS_API
#include <alsa/asoundlib.h>
#undef ALSA_PCM_NEW_HW_PARAMS_API
#undef ALSA_PCM_NEW_SW_PARAMS_API


/* Parameters of the particular test - change to suit */
#define TEST_ALSA_FORMAT SND_PCM_FORMAT_S16
#define TEST_SAMPLE_RATES {22050, 32000, 44100, 48000, 96000, 0} /* An array initialisation for test rates, zero terminate */
#define TEST_HOST_CHANNELS 6
#define TEST_HOST_DEVICE_NAME "front" //"surround40" //"surround51"
#define TEST_STREAM_DIRECTION StreamDirection_Out

#define RATE_MAX_DEVIATE_RATIO 100


/* Extracts from portaudio.h: */
typedef int PaError;
typedef enum PaErrorCode
{
    paNoError = 0,
    paUnanticipatedHostError = -9999,
    paInvalidChannelCount,
    paInvalidSampleRate,
    paSampleFormatNotSupported,
    paBadIODeviceCombination,
    paDeviceUnavailable,
    paIncompatibleStreamHostApi,
} PaErrorCode;

typedef int PaDeviceIndex;
typedef double PaTime;
typedef unsigned long PaSampleFormat;

typedef struct PaStreamParameters
{
    PaDeviceIndex device;
    int channelCount;
    PaSampleFormat sampleFormat;
    PaTime suggestedLatency;
    void *hostApiSpecificStreamInfo;

} PaStreamParameters;

typedef enum
{
    StreamDirection_In,
    StreamDirection_Out
} StreamDirection;

typedef struct PaAlsaStreamInfo
{
    unsigned long size;
    int hostApiType;
    unsigned long version;

    const char *deviceString;
}
PaAlsaStreamInfo;


/* Local functions derived from pa_linux_alsa.c: */
int Alsa_OpenPcm( snd_pcm_t **pcmp, const char *name, snd_pcm_stream_t stream, int mode, int waitOnBusy )
{
    int ret, tries = 0, maxTries = waitOnBusy ? 100 : 0;

    ret = snd_pcm_open( pcmp, name, stream, mode );

    for( tries = 0; tries < maxTries && -EBUSY == ret; ++tries )
    {
        usleep( 10000 );
        ret = snd_pcm_open( pcmp, name, stream, mode );
        if( -EBUSY != ret )
        {
            printf( "%s: Successfully opened initially busy device after %d tries\n", __FUNCTION__, tries );
        }
    }
    if( -EBUSY == ret )
    {
        printf( "%s: Failed to open busy device '%s'\n", __FUNCTION__, name );
    }
    else
    {
        if( ret < 0 )
            printf( "%s: Opened device '%s' ptr[%p] - result: [%d:%s]\n", __FUNCTION__, name, *pcmp, ret, snd_strerror(ret) );
    }

    return ret;
}


static PaError AlsaOpen( const PaStreamParameters *params, StreamDirection streamDir, snd_pcm_t **pcm )
{
    PaError result = paNoError;
    int ret;
    const char* deviceName = NULL;
    PaAlsaStreamInfo *streamInfo = (PaAlsaStreamInfo *)params->hostApiSpecificStreamInfo;

    if( !streamInfo )
    {
        deviceName = TEST_HOST_DEVICE_NAME;
    }
    else
        deviceName = streamInfo->deviceString;

    //printf( "%s: Opening device %s\n", __FUNCTION__, deviceName );
    if( (ret = Alsa_OpenPcm( pcm, deviceName, streamDir == StreamDirection_In ? SND_PCM_STREAM_CAPTURE : SND_PCM_STREAM_PLAYBACK,
                    SND_PCM_NONBLOCK, 1 )) < 0 )
    {
        /* Not to be closed */
        *pcm = NULL;
        if( ret < 0 )
            return ( -EBUSY == ret ? paDeviceUnavailable : paBadIODeviceCombination );
    }
    if( snd_pcm_nonblock( *pcm, 0 ) )
        return paUnanticipatedHostError;

    return result;
}


/* Set the stream sample rate to a nominal value requested; allow only a defined tolerance range */
int Alsa_SetApproximateSampleRate( snd_pcm_t *pcm, snd_pcm_hw_params_t *hwParams, double sampleRate )
{
    PaError result = paNoError;
    unsigned int reqRate, setRate, deviation;

    assert( pcm && hwParams );

    /* The Alsa sample rate is set by integer value; also the actual rate may differ */
    reqRate = setRate = (unsigned int) sampleRate;

    if( snd_pcm_hw_params_set_rate_near( pcm, hwParams, &setRate, NULL ) < 0 )
        return paUnanticipatedHostError;
    /* The value actually set will be put in 'setRate' (may be way off); check the deviation as a proportion
     * of the requested-rate with reference to the max-deviate-ratio (larger values allow less deviation) */
    deviation = abs( setRate - reqRate );
    if( deviation > 0 && deviation * RATE_MAX_DEVIATE_RATIO > reqRate )
        result = paInvalidSampleRate;

    return result;
}


static PaError TestParameters( const PaStreamParameters *parameters, double sampleRate, StreamDirection streamDir )
{
    PaError result = paNoError;
    snd_pcm_t *pcm = NULL;
    unsigned int numHostChannels;
    snd_pcm_format_t alsaFormat = TEST_ALSA_FORMAT;
    snd_pcm_hw_params_t *hwParams;

    snd_pcm_hw_params_alloca( &hwParams );

    if( !parameters->hostApiSpecificStreamInfo )
    {
        numHostChannels = TEST_HOST_CHANNELS;
    }
    else
        numHostChannels = parameters->channelCount;

    if( AlsaOpen( parameters, streamDir, &pcm ) < 0)
    {
        result = paUnanticipatedHostError;
        printf( "%s: AlsaOpen failed\n", __FUNCTION__ );
        goto error;
    }

    snd_pcm_hw_params_any( pcm, hwParams );

    if( Alsa_SetApproximateSampleRate( pcm, hwParams, sampleRate ) < 0 )
    {
        result = paInvalidSampleRate;
        goto error;
    }

    if( snd_pcm_hw_params_set_channels( pcm, hwParams, numHostChannels ) < 0 )
    {
        result = paInvalidChannelCount;
        goto error;
    }

    /* Some specific hardware (reported: Audio8 DJ) can fail with assertion during this step. */
    if( snd_pcm_hw_params_set_format( pcm, hwParams, alsaFormat ) < 0 )
        return paSampleFormatNotSupported;

    {
        /* It happens that this call fails because the device is busy */
        int ret = 0;
        if( ( ret = snd_pcm_hw_params( pcm, hwParams ) ) < 0 )
        {
            if( -EINVAL == ret )
            {
                /* Don't know what to return here */
                result = paBadIODeviceCombination;
                goto error;
            }
            else if( -EBUSY == ret )
            {
                result = paDeviceUnavailable;
                printf( "%s: Device is busy\n", __FUNCTION__ );
            }
            else
            {
                result = paUnanticipatedHostError;
            }

            if( ret < 0 )
                return result;
        }
    }

end:
    if( pcm )
    {
        snd_pcm_close( pcm );
    }
    return result;

error:
    goto end;
}



/* This will test each of the listed sample rates at the given format, device and num channels */
int main()
{
    PaStreamParameters strParams;
    PaError testResult = paNoError;
    char *testMessg;
    int i = 0, testRates[] = TEST_SAMPLE_RATES;

    strParams.hostApiSpecificStreamInfo = NULL;
    strParams.channelCount = TEST_HOST_CHANNELS;

    printf( "Testing device %s\n", TEST_HOST_DEVICE_NAME );
    printf( "Num channels %u\n", TEST_HOST_CHANNELS );

    while( testRates[i] > 0 )
    {
        printf( "Testing rate: %i   ", testRates[i] );
        testResult = TestParameters( &strParams, testRates[i], TEST_STREAM_DIRECTION);

        switch( testResult )
        {
            case paNoError: testMessg = "Success!!!"; break;
            case paInvalidSampleRate: testMessg = "Invalid Sample Rate"; break;
            case paInvalidChannelCount: testMessg = "Invalid Num Channels"; break;
            case paSampleFormatNotSupported: testMessg = "Invalid Format"; break;
            default: testMessg = "Unexpected Result???";
        }
        printf("Result:...%s\n", testMessg );

        i++;
    }

    return testResult;
}

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: Assert in pcm_params.c

[Raymond Yau]

> > > The following assert is being hit in pcm_params.c:
> > >
> > > "pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0'
> > > failed."
> > >
> > > This is from a developer using Portaudio in his own application; I
have
> > > yet to ascertain full details, but it is trying successive sample
rates
> > > to see which are valid.
> >
> > Further info: this occurs with an Intel motherboard/soundcard,
attempting
> > to open and config the stream at 44100 using front, surround or hdmi
pcm,
> > having previously opened and tried at a lower, not-supported samplerate,
> > and closed. AFAIK other pcms work OK.
> >
> > The assert is hit with all current Debian and Ubuntu distros, for
example
> >      Debian 8 (jessie) 32 bit:  kernel 3.16.0-4-686-pae (Alsa 1.0.28)
> > but is not seen with Fedora 20 or OpenSuse 12.1 (do they have asserts
> > off?).
> >
> > > Does this point to a flaw in the configuration or possibly a bug in
> > > Alsa-lib or can it occur just as a result of misuse of the Alsa API?
> >
> > I will try to conceive some more tests.  How can we debug this further?
>
> A minimal self-contained demo program ('test-format') has been developed
and
> is attached, that demonstrates the issue 100% on the reporters machine
> (HDA-Intel, 6-ch I believe).  The output is:
>
> root@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
>
> Alsa-info is at:
>
> http://www.alsa-project.org/db/?f=19dfeee29f73007e61a00a8fabe3c958f7cb8e87
>
> This apparently happens with or without Pulseaudio running, with just the
> single 44100 rate, and also with surround devices.  Also, on all current
> Debian and Ubuntu - we have focused on Jessie.
>
> I do not have a machine with similar hardware, so cannot duplicate the
> results.

Cannot reproduce the assert

But the only plugin associated with front device is softvol

Do the assert still occur with hw device ?(without softvol plugin)

You need to provide debug output by  define RULES_DEBUG in pcm_params.c

What value do the distribution use for hda prealloc max size ?

snd_pcm_hw_params() may fail with invalid  argument even when
pa_isFormataupported return true

Re: Assert in pcm_params.c

[Raymond Yau]

> > The following assert is being hit in pcm_params.c:
> > >
> > > "pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0'
> > > failed."
> > >
> > > This is from a developer using Portaudio in his own application; I have
> > > yet to ascertain full details, but it is trying successive sample rates
> > > to see which are valid.
> >
> > Further info: this occurs with an Intel motherboard/soundcard, attempting
> > to open and config the stream at 44100 using front, surround or hdmi pcm,
> > having previously opened and tried at a lower, not-supported samplerate,
> > and closed. AFAIK other pcms work OK.
> >
> > The assert is hit with all current Debian and Ubuntu distros, for example
> >      Debian 8 (jessie) 32 bit:  kernel 3.16.0-4-686-pae (Alsa 1.0.28)
> > but is not seen with Fedora 20 or OpenSuse 12.1 (do they have asserts
> > off?).
> >
> > > Does this point to a flaw in the configuration or possibly a bug in
> > > Alsa-lib or can it occur just as a result of misuse of the Alsa API?
> >
> > I will try to conceive some more tests.  How can we debug this further?
>
> A minimal self-contained demo program ('test-format') has been developed
> and
> is attached, that demonstrates the issue 100% on the reporters machine
> (HDA-Intel, 6-ch I believe).  The output is:
>
> root@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
>

> Alsa-info is at:
>
> http://www.alsa-project.org/db/?f=19dfeee29f73007e61a00a8fabe3c958f7cb8e87
>
> This apparently happens with or without Pulseaudio running, with just the
> single 44100 rate, and also with surround devices.  Also, on all current
> Debian and Ubuntu - we have focused on Jessie.
>
> I do not have a machine with similar hardware, so cannot duplicate the
> results.
>

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda/hda_intel.c?id=2ae66c26550cd94b0e2606a9275eb0ab7070ad0e

seem assert only occur when hda controller support arbitrary period size
(align_buffer_size=0) and softvol plugin ,

your program return invalid argument -22 without softvol plugin

Re: Assert in pcm_params.c

[Takashi Iwai]

At Fri, 1 May 2015 08:36:47 +0100,
Alan Horstmann wrote:
> 
> On Monday 20 April 2015 12:17, Alan Horstmann wrote:
> > On Saturday 18 April 2015 09:08, Alan Horstmann wrote:
> > > The following assert is being hit in pcm_params.c:
> > >
> > > "pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0'
> > > failed."
> > >
> > > This is from a developer using Portaudio in his own application; I have
> > > yet to ascertain full details, but it is trying successive sample rates
> > > to see which are valid.
> >
> > Further info: this occurs with an Intel motherboard/soundcard, attempting
> > to open and config the stream at 44100 using front, surround or hdmi pcm,
> > having previously opened and tried at a lower, not-supported samplerate,
> > and closed. AFAIK other pcms work OK.
> >
> > The assert is hit with all current Debian and Ubuntu distros, for example
> >      Debian 8 (jessie) 32 bit:  kernel 3.16.0-4-686-pae (Alsa 1.0.28)
> > but is not seen with Fedora 20 or OpenSuse 12.1 (do they have asserts
> > off?).
> >
> > > Does this point to a flaw in the configuration or possibly a bug in
> > > Alsa-lib or can it occur just as a result of misuse of the Alsa API?
> >
> > I will try to conceive some more tests.  How can we debug this further?
> 
> A minimal self-contained demo program ('test-format') has been developed and 
> is attached, that demonstrates the issue 100% on the reporters machine 
> (HDA-Intel, 6-ch I believe).  The output is:
> 
> root@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
> 
> Alsa-info is at:
> 
> http://www.alsa-project.org/db/?f=19dfeee29f73007e61a00a8fabe3c958f7cb8e87
> 
> This apparently happens with or without Pulseaudio running, with just the 
> single 44100 rate, and also with surround devices.  Also, on all current 
> Debian and Ubuntu - we have focused on Jessie.
> 
> I do not have a machine with similar hardware, so cannot duplicate the 
> results.
> 
> Any comments, ideas etc would be appreciated.

I also can't reproduce this.  So this must be pretty specific to the
setup.

Could you give the exact condition to trigger the problem?  Also, this
happens certainly with the latest alsa-lib?


thanks,

Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Assert in pcm_params.c

[Raymond Yau]

> > > > The following assert is being hit in pcm_params.c:
> > > >
> > > > "pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0'
> > > > failed."
> > > >
> > > > This is from a developer using Portaudio in his own application; I
have
> > > > yet to ascertain full details, but it is trying successive sample
rates
> > > > to see which are valid.
> > >
> > > Further info: this occurs with an Intel motherboard/soundcard,
attempting
> > > to open and config the stream at 44100 using front, surround or hdmi
pcm,
> > > having previously opened and tried at a lower, not-supported
samplerate,
> > > and closed. AFAIK other pcms work OK.
> > >
> > > The assert is hit with all current Debian and Ubuntu distros, for
example
> > >      Debian 8 (jessie) 32 bit:  kernel 3.16.0-4-686-pae (Alsa 1.0.28)
> > > but is not seen with Fedora 20 or OpenSuse 12.1 (do they have asserts
> > > off?).
> > >
> > > > Does this point to a flaw in the configuration or possibly a bug in
> > > > Alsa-lib or can it occur just as a result of misuse of the Alsa API?
> > >
> > > I will try to conceive some more tests.  How can we debug this
further?
> >
> > A minimal self-contained demo program ('test-format') has been
developed and
> > is attached, that demonstrates the issue 100% on the reporters machine
> > (HDA-Intel, 6-ch I believe).  The output is:
> >
> > root@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
> >
> > Alsa-info is at:
> >
> >
http://www.alsa-project.org/db/?f=19dfeee29f73007e61a00a8fabe3c958f7cb8e87
> >
> > This apparently happens with or without Pulseaudio running, with just
the
> > single 44100 rate, and also with surround devices.  Also, on all current
> > Debian and Ubuntu - we have focused on Jessie.
> >
> > I do not have a machine with similar hardware, so cannot duplicate the
> > results.
> >
> > Any comments, ideas etc would be appreciated.
>
> I also can't reproduce this.  So this must be pretty specific to the
> setup.
>
> Could you give the exact condition to trigger the problem?  Also, this
> happens certainly with the latest alsa-lib?

It can be reproduced by modify snd-dummy to use azx_pcm_hw

6 channels and softvol similar to hda controller which support arbitrary
period size

snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_BUFFER_BYTES, 4);

snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 4);

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda?id=2ae66c26550cd94b0e2606a9275eb0ab7070ad0e

Slave can return err when call schange

snd_pcm_hw_params_t slave_params;
int err;
err = sprepare(pcm, &slave_params);
assert(err >= 0);
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);
return err;

Re: Assert in pcm_params.c

[Alan Horstmann]

On Tuesday 19 May 2015 13:01, Takashi Iwai wrote:
> At Fri, 1 May 2015 08:36:47 +0100, Alan Horstmann wrote:
> > A minimal self-contained demo program ('test-format') has been developed
> > and is attached, that demonstrates the issue 100% on the reporters
> > machine (HDA-Intel, 6-ch I believe).  The output is:
> >
> > root@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
> >
> > Alsa-info is at:
> >
> > http://www.alsa-project.org/db/?f=19dfeee29f73007e61a00a8fabe3c958f7cb8e8
> >7
> >
> > This apparently happens with or without Pulseaudio running, with just the
> > single 44100 rate, and also with surround devices.  Also, on all current
> > Debian and Ubuntu - we have focused on Jessie.
> >
> > I do not have a machine with similar hardware, so cannot duplicate the
> > results.
> >
> > Any comments, ideas etc would be appreciated.
>
> I also can't reproduce this.  So this must be pretty specific to the
> setup.
>
> Could you give the exact condition to trigger the problem?  Also, this
> happens certainly with the latest alsa-lib?

Thanks for taking a look.  Just compiling and running that test program, on 
the reporter's machine, which has some sort of multi-channel HDA-Intel, is 
100% reproducible. The Alsa-lib must be the one provided by Debian Jessie 
(which was released 25.4.2015); 1.0.28 I think.  Does the Alsa-info give 
enough details - I can ask any specific questions.

However, Raymond seems to have some ideas of a possible cause, in connection 
with arbitrary period size and softvol; is that plausible?

Regards

Alan
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Assert in pcm_params.c

[Raymond Yau]

> > > A minimal self-contained demo program ('test-format') has been
developed
> > > and is attached, that demonstrates the issue 100% on the reporters
> > > machine (HDA-Intel, 6-ch I believe).  The output is:
> > >
> > > root@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
> > >
> > > Alsa-info is at:
> > >
> > >
http://www.alsa-project.org/db/?f=19dfeee29f73007e61a00a8fabe3c958f7cb8e8
> > >7
> > >

00:1b.0 0403: 8086:269a (rev 09)
Subsystem: 8086:0419

{ PCI_DEVICE(0x8086, 0x269a),
  .driver_data = AZX_DRIVER_ICH | AZX_DCAPS_INTEL_ICH },

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda?id=103884a351a221553095c509a1dbbbf7d4fd9b05

#define AZX_DCAPS_INTEL_ICH \
(AZX_DCAPS_OLD_SSYNC | AZX_DCAPS_NO_ALIGN_BUFSIZE)

Only AZX_DCAPS_INTEL_ICH use AZX_DCAPS_NO_ALIGN_BUFSIZE

> > > This apparently happens with or without Pulseaudio running, with just
the
> > > single 44100 rate, and also with surround devices.  Also, on all
current
> > > Debian and Ubuntu - we have focused on Jessie.
> > >
> > > I do not have a machine with similar hardware, so cannot duplicate the
> > > results.
> > >
> > > Any comments, ideas etc would be appreciated.
> >
> > I also can't reproduce this.  So this must be pretty specific to the
> > setup.
> >
> > Could you give the exact condition to trigger the problem?  Also, this
> > happens certainly with the latest alsa-lib?
>
> Thanks for taking a look.  Just compiling and running that test program,
on
> the reporter's machine, which has some sort of multi-channel HDA-Intel, is
> 100% reproducible. The Alsa-lib must be the one provided by Debian Jessie
> (which was released 25.4.2015); 1.0.28 I think.  Does the Alsa-info give
> enough details - I can ask any specific questions.
>

snd_hda_prealloc_size may affect the result

when your program let alsa lib to determine those buffer size, period and
period size , snd_pcm_hw_params return error on 6 channels for some hda
controllers

Your program  return error when using "hw" instead of  assert  when using
"front" with 6 channels

Re: Assert in pcm_params.c

[Takashi Iwai]

At Tue, 19 May 2015 20:22:50 +0100,
Alan Horstmann wrote:
> 
> On Tuesday 19 May 2015 13:01, Takashi Iwai wrote:
> > At Fri, 1 May 2015 08:36:47 +0100, Alan Horstmann wrote:
> > > A minimal self-contained demo program ('test-format') has been developed
> > > and is attached, that demonstrates the issue 100% on the reporters
> > > machine (HDA-Intel, 6-ch I believe).  The output is:
> > >
> > > root@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
> > >
> > > Alsa-info is at:
> > >
> > > http://www.alsa-project.org/db/?f=19dfeee29f73007e61a00a8fabe3c958f7cb8e8
> > >7
> > >
> > > This apparently happens with or without Pulseaudio running, with just the
> > > single 44100 rate, and also with surround devices.  Also, on all current
> > > Debian and Ubuntu - we have focused on Jessie.
> > >
> > > I do not have a machine with similar hardware, so cannot duplicate the
> > > results.
> > >
> > > Any comments, ideas etc would be appreciated.
> >
> > I also can't reproduce this.  So this must be pretty specific to the
> > setup.
> >
> > Could you give the exact condition to trigger the problem?  Also, this
> > happens certainly with the latest alsa-lib?
> 
> Thanks for taking a look.  Just compiling and running that test program, on 
> the reporter's machine, which has some sort of multi-channel HDA-Intel, is 
> 100% reproducible. The Alsa-lib must be the one provided by Debian Jessie 
> (which was released 25.4.2015); 1.0.28 I think.  Does the Alsa-info give 
> enough details - I can ask any specific questions.
> 
> However, Raymond seems to have some ideas of a possible cause, in connection 
> with arbitrary period size and softvol; is that plausible?

Possibly, but I wonder why I couldn't see it when I tried with
different module options.

In anyway, the fix would be simple, the patch like below.  Could you
check whether it actually fixes your issue?


thanks,

Takashi

---
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);
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Assert in pcm_params.c

[Raymond Yau]

> > > > A minimal self-contained demo program ('test-format') has been
developed
> > > > and is attached, that demonstrates the issue 100% on the reporters
> > > > machine (HDA-Intel, 6-ch I believe).  The output is:
> > > >
> > > > root@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
> > > >
> > > > Alsa-info is at:
> > > >
> > > >
http://www.alsa-project.org/db/?f=19dfeee29f73007e61a00a8fabe3c958f7cb8e8
> > > >7
> > > >
> > > > This apparently happens with or without Pulseaudio running, with
just the
> > > > single 44100 rate, and also with surround devices.  Also, on all
current
> > > > Debian and Ubuntu - we have focused on Jessie.
> > > >
> > > > I do not have a machine with similar hardware, so cannot duplicate
the
> > > > results.
> > > >
> > > > Any comments, ideas etc would be appreciated.
> > >
> > > I also can't reproduce this.  So this must be pretty specific to the
> > > setup.
> > >
> > > Could you give the exact condition to trigger the problem?  Also, this
> > > happens certainly with the latest alsa-lib?
> >
> > Thanks for taking a look.  Just compiling and running that test
program, on
> > the reporter's machine, which has some sort of multi-channel HDA-Intel,
is
> > 100% reproducible. The Alsa-lib must be the one provided by Debian
Jessie
> > (which was released 25.4.2015); 1.0.28 I think.  Does the Alsa-info give
> > enough details - I can ask any specific questions.
> >
> > However, Raymond seems to have some ideas of a possible cause, in
connection
> > with arbitrary period size and softvol; is that plausible?
>
> Possibly, but I wonder why I couldn't see it when I tried with
> different module options.
>
> In anyway, the fix would be simple, the patch like below.  Could you
> check whether it actually fixes your issue?
>

http://music.columbia.edu/pipermail/portaudio/2015-May/016773.html

i7 test # ./test-format
Testing device front
Num channels 6
Testing rate: 22050   Result:...Invalid Sample Rate
Testing rate: 32000   Result:...Invalid Sample Rate
Testing rate: 44100   Result:...Unexpected Result???
Testing rate: 48000   Result:...Unexpected Result???
Testing rate: 96000   Result:...Unexpected Result???
i7 test # uname -r
3.13.0-sabayon

Your program should show snd_strerror(err) instead of Unexpected Result ???

It is strange that it fail at 48000Hz and 96000Hz

What is snd_hda_prealloc_size used by 3.13.0-sabayon ?

You need to define RULES_DEBUG in pcm_params.c to provide debug output

Re: Assert in pcm_params.c

[Alan Horstmann]

On Wednesday 20 May 2015 07:36, Takashi Iwai wrote:
> At Tue, 19 May 2015 20:22:50 +0100,
>
> Alan Horstmann wrote:
> > On Tuesday 19 May 2015 13:01, Takashi Iwai wrote:
> > > At Fri, 1 May 2015 08:36:47 +0100, Alan Horstmann wrote:
> > > > A minimal self-contained demo program ('test-format') has been
> > > > developed and is attached, that demonstrates the issue 100% on the
> > > > reporters machine (HDA-Intel, 6-ch I believe).  The output is:
> > > >
> > > > root@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
> > > >
> > > > Alsa-info is at:
> > > >
> > > > http://www.alsa-project.org/db/?f=19dfeee29f73007e61a00a8fabe3c958f7c
> > > >b8e8 7
> > > >
> > > > This apparently happens with or without Pulseaudio running, with just
> > > > the single 44100 rate, and also with surround devices.  Also, on all
> > > > current Debian and Ubuntu - we have focused on Jessie.
> > > >
> > > > I do not have a machine with similar hardware, so cannot duplicate
> > > > the results.
> > > >
> > > > Any comments, ideas etc would be appreciated.
> > >
> > > I also can't reproduce this.  So this must be pretty specific to the
> > > setup.
> > >
> > > Could you give the exact condition to trigger the problem?  Also, this
> > > happens certainly with the latest alsa-lib?
> >
> > Thanks for taking a look.  Just compiling and running that test program,
> > on the reporter's machine, which has some sort of multi-channel
> > HDA-Intel, is 100% reproducible. The Alsa-lib must be the one provided by
> > Debian Jessie (which was released 25.4.2015); 1.0.28 I think.  Does the
> > Alsa-info give enough details - I can ask any specific questions.
> >
> > However, Raymond seems to have some ideas of a possible cause, in
> > connection with arbitrary period size and softvol; is that plausible?
>
> Possibly, but I wonder why I couldn't see it when I tried with
> different module options.
>
> In anyway, the fix would be simple, the patch like below.  Could you
> check whether it actually fixes your issue?

I've had a positive confirmation that the patch removing the asserts does fix 
the 'crash' in the reporter's system.  So instead it is simply a failure of 
the snd_pcm_hw_params() call, which ultimately can be handled in the users 
code.

I do wonder (as does Raymond) why this fails.  Is 6-chans expected to fail on 
'front'?  In particular the earlier setting of channels/rate/format does not 
fail?  Perhaps I will ask for RULES_DEBUG enabled?

Regards

Alan
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Assert in pcm_params.c

[Takashi Iwai]

At Thu, 21 May 2015 16:56:04 +0100,
Alan Horstmann wrote:
> 
> On Wednesday 20 May 2015 07:36, Takashi Iwai wrote:
> > At Tue, 19 May 2015 20:22:50 +0100,
> >
> > Alan Horstmann wrote:
> > > On Tuesday 19 May 2015 13:01, Takashi Iwai wrote:
> > > > At Fri, 1 May 2015 08:36:47 +0100, Alan Horstmann wrote:
> > > > > A minimal self-contained demo program ('test-format') has been
> > > > > developed and is attached, that demonstrates the issue 100% on the
> > > > > reporters machine (HDA-Intel, 6-ch I believe).  The output is:
> > > > >
> > > > > root@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
> > > > >
> > > > > Alsa-info is at:
> > > > >
> > > > > http://www.alsa-project.org/db/?f=19dfeee29f73007e61a00a8fabe3c958f7c
> > > > >b8e8 7
> > > > >
> > > > > This apparently happens with or without Pulseaudio running, with just
> > > > > the single 44100 rate, and also with surround devices.  Also, on all
> > > > > current Debian and Ubuntu - we have focused on Jessie.
> > > > >
> > > > > I do not have a machine with similar hardware, so cannot duplicate
> > > > > the results.
> > > > >
> > > > > Any comments, ideas etc would be appreciated.
> > > >
> > > > I also can't reproduce this.  So this must be pretty specific to the
> > > > setup.
> > > >
> > > > Could you give the exact condition to trigger the problem?  Also, this
> > > > happens certainly with the latest alsa-lib?
> > >
> > > Thanks for taking a look.  Just compiling and running that test program,
> > > on the reporter's machine, which has some sort of multi-channel
> > > HDA-Intel, is 100% reproducible. The Alsa-lib must be the one provided by
> > > Debian Jessie (which was released 25.4.2015); 1.0.28 I think.  Does the
> > > Alsa-info give enough details - I can ask any specific questions.
> > >
> > > However, Raymond seems to have some ideas of a possible cause, in
> > > connection with arbitrary period size and softvol; is that plausible?
> >
> > Possibly, but I wonder why I couldn't see it when I tried with
> > different module options.
> >
> > In anyway, the fix would be simple, the patch like below.  Could you
> > check whether it actually fixes your issue?
> 
> I've had a positive confirmation that the patch removing the asserts does fix 
> the 'crash' in the reporter's system.  So instead it is simply a failure of 
> the snd_pcm_hw_params() call, which ultimately can be handled in the users 
> code.

OK, I pushed the fix to git repo now.

> I do wonder (as does Raymond) why this fails.  Is 6-chans expected to fail on 
> 'front'?  In particular the earlier setting of channels/rate/format does not 
> fail?  Perhaps I will ask for RULES_DEBUG enabled?

Likely the alignment issue: 6 channels can't fit always with 128 byte 
constraint that are required by some hardware chips.


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Assert in pcm_params.c

[Alan Horstmann]

On Thursday 21 May 2015 18:26, Takashi Iwai wrote:
> At Thu, 21 May 2015 16:56:04 +0100,
>
> Alan Horstmann wrote:
> > On Wednesday 20 May 2015 07:36, Takashi Iwai wrote:

<snip>

> > > In anyway, the fix would be simple, the patch like below.  Could you
> > > check whether it actually fixes your issue?
> >
> > I've had a positive confirmation that the patch removing the asserts does
> > fix the 'crash' in the reporter's system.  So instead it is simply a
> > failure of the snd_pcm_hw_params() call, which ultimately can be handled
> > in the users code.
>
> OK, I pushed the fix to git repo now.

Is this something that should go to stable so it is more likely to be 
backported to slower moving distros, eg Debian Jessie, or is that not how it 
works?

> > I do wonder (as does Raymond) why this fails.  Is 6-chans expected to
> > fail on 'front'?  In particular the earlier setting of
> > channels/rate/format does not fail?  Perhaps I will ask for RULES_DEBUG
> > enabled?
>
> Likely the alignment issue: 6 channels can't fit always with 128 byte
> constraint that are required by some hardware chips.

Hmm, it is only an issue with the pcms like front, surround though, not hw?

Regards

Alan

Re: Assert in pcm_params.c

[Takashi Iwai]

At Thu, 21 May 2015 19:10:30 +0100,
Alan Horstmann wrote:
> 
> On Thursday 21 May 2015 18:26, Takashi Iwai wrote:
> > At Thu, 21 May 2015 16:56:04 +0100,
> >
> > Alan Horstmann wrote:
> > > On Wednesday 20 May 2015 07:36, Takashi Iwai wrote:
> 
> <snip>
> 
> > > > In anyway, the fix would be simple, the patch like below.  Could you
> > > > check whether it actually fixes your issue?
> > >
> > > I've had a positive confirmation that the patch removing the asserts does
> > > fix the 'crash' in the reporter's system.  So instead it is simply a
> > > failure of the snd_pcm_hw_params() call, which ultimately can be handled
> > > in the users code.
> >
> > OK, I pushed the fix to git repo now.
> 
> Is this something that should go to stable so it is more likely to be 
> backported to slower moving distros, eg Debian Jessie, or is that not how it 
> works?

It'll be included in the next alsa-lib release.

> > > I do wonder (as does Raymond) why this fails.  Is 6-chans expected to
> > > fail on 'front'?  In particular the earlier setting of
> > > channels/rate/format does not fail?  Perhaps I will ask for RULES_DEBUG
> > > enabled?
> >
> > Likely the alignment issue: 6 channels can't fit always with 128 byte
> > constraint that are required by some hardware chips.
> 
> Hmm, it is only an issue with the pcms like front, surround though, not hw?

hw might have the same alignment problem, but it hasn't hit assert().
The faulty assert() was only in the code path for plugins.


Takashi

Re: Assert in pcm_params.c

[Raymond Yau]

> I've had a positive confirmation that the patch removing the asserts does
fix
> the 'crash' in the reporter's system.  So instead it is simply a failure
of
> the snd_pcm_hw_params() call, which ultimately can be handled in the users
> code.
>
> I do wonder (as does Raymond) why this fails.  Is 6-chans expected to
fail on
> 'front'?  In particular the earlier setting of channels/rate/format does
not
> fail?  Perhaps I will ask for RULES_DEBUG enabled?
>
>

period_max is only 32 , this mean that some combination are not possible

Re: Assert in pcm_params.c

[Raymond Yau]

2014-02-18 4:56 GMT+08:00 Alan Horstmann <gineera@aspect135.co.uk>:

> Hi,
>
> I am trying to assist in a case that is getting this assert:-
>
> pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0' failed.
>
> and wondered if anyone could shed some light on what is likely to cause
> that,
> and whether it indicates an underlying fault?
>

you need to know which plugin  is used ?

this occur when error return by snd_pcm_xxxxxx_hw_refine_schange in the
plugin

e.g. route plugin in

https://bugzilla.redhat.com/show_bug.cgi?id=1051884



> The system (not mine) runs Linux Mint 13 (kernel 3.2.0) with PulseAudio,
> and
> we are debugging weird behaviour during Portaudio initialisation.  It is
> struggling to get consistent access to the Alsa devices, often retrying
> many
> times.
>
>

Assert in pcm_params.c

[Alan Horstmann]

Hi,

I am trying to assist in a case that is getting this assert:-

pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0' failed.

and wondered if anyone could shed some light on what is likely to cause that, 
and whether it indicates an underlying fault?

The system (not mine) runs Linux Mint 13 (kernel 3.2.0) with PulseAudio, and 
we are debugging weird behaviour during Portaudio initialisation.  It is 
struggling to get consistent access to the Alsa devices, often retrying many 
times.

Any pointers would be appreciated.

Thanks

Alan