• 1
  • 94
  • 95
  • 96(current)
  • 97
  • 98
  • 156
OpenELEC Testbuilds for RaspberryPi Part 3 (Kodi 14.0)
(2014-09-24, 15:16)plugh Wrote: Can't comments on all your cases, but the bcm2835 driver (both analog and hdmi) does not declare support for S24_LE

Actually xbmc doesn't use alsa for hdmi/analogue outputs. It uses openmax directly (and does support 8/16/24/32/float audio formats).

Internally xbmc uses ffmpeg's libswresample for format conversion. However the Pi has a GPU accelerated path for this which means libswresample is not used.

I did suspect that the GPU path might have a bug with 24-bit formats, but I get get the same noise with the GPU accelerated path disabled.
This fact suggests the bug is not in ffmpeg's libswresample as I believe I'm seeing it with that path disabled

Note there are two examples of noise produced:
One when using HifiBerry, presumably with mostly float audio (the output of most of ffmeg's audio decoders) . This will probably exercise a float->S24_LE conversion.
One when using s24_le.wav with HDMI audio output. This will probably exercise a S24_LE->float conversion (I'll have to check exactly what AudioEngine chooses for the sink in this case).

Possibly there are two bugs. One is a general disagreement about where bytes go in a S24 WAV file.
The other is on the path from xbmc->hifiberry driver does something wrong with S24.
BTW, the S24_LE file I supplied is slightly 'wrong'. I discovered the alsa plugin stack I'm using (to boost volume) apparently sign-extends the 24 bit data (alsa plugin bug?). It should not matter, as S24_LE consumers are supposed to ignore the high byte. However for accuracies sake, attached is an unprocessed (even quieter) S24_LE sample.
(2014-09-24, 15:46)plugh Wrote: BTW, the S24_LE file I supplied is slightly 'wrong'. I discovered the alsa plugin stack I'm using (to boost volume) apparently sign-extends the 24 bit data (alsa plugin bug?). It should not matter, as S24_LE consumers are supposed to ignore the high byte. However for accuracies sake, attached is an unprocessed (even quieter) S24_LE sample.

This now now plays as noise with everything (including audacity).

Audacity is now full range. Looks like left channel is white noise and right channel is doing some chirping that looks like it is clipped.
Yes, only one channel of real data (it's a mono mic), other channel all zeros.

That is an interesting result. In a post in RaspberryPi forum, I noted that the i2s hardware was capable of doing sign extension for non-16/32 bit capture, and was a trivial change. (Edit one line in i2s driver - nobody commented) But since (by definition, as I understand it) the contents of the high byte should be immaterial I didn't pursue it.

Where do you want to go from here? My interest was in establishing whether there was a bug in the driver(s) and/or hardware, which I'd say the aplay test answered (no), and whether an alsa config file might offer an alternative to killing support in the drivers for problematic software (awaiting boberze). You are obviously more knowledgeable about the higher level audio paths. Is there anything else I can contribute to the problem analysis at this point?
(2014-09-24, 16:31)plugh Wrote: Yes, only one channel of real data (it's a mono mic), other channel all zeros.

But it isn't according to Audacity. The file looks like:
Image
Hexdump the file. All zeroes in one channel.

(I'd really like to get that 'mono' patch in i2s driver - hint hint)

BTW, what do you think - Should I pursue the 'sign-extend' thing, too? We apparently have some software 'out there' that thinks S24_LE should be sign-extended into high byte...

Edit: Your comment about 'white noise' in left channel - that's ambient background, I wasn't speaking during that capture. I can supply one with me speaking, if you want.
(2014-09-23, 23:24)Unfledged Wrote: Short sample here, and if there's anything else I can provide to help track down the issue, let me know.

I've pushed a fix for this file. Please test in next build.
(2014-09-24, 13:32)plugh Wrote: Look at the last line of the release announcement post. That is what changed.

If it's not to much trouble, I'd appreciate you running a few more tests under the previous build?

1) play my sample with xbmc (with no asound config)
2) add the following asound config
Code:
pcm.!default {
    type plug
    slave {
        pcm {
        type hw
        card 0
        format S16_LE
        rate "unchanged"
        channels "unchanged"
}   }   }
3) now run aplay test(s) with '-D default', and xbmc tests

Note that you might have to experiment with the config file. Try aplay with it as shown; if aplay gives error, remove rate and channels lines. My expectation is you will get noise with test (1), and the (3) tests will all 'work'.

What that config file (should) do is give YOU control over what format the pcm data is delivered to the DAC. (FYI -the driver supports S16_LE, S24_LE, and S32_LE, except for the new build which disabled S24_LE again). The ALSA 'plug' plugin will do a format conversion to the format you specify in the config file if needed (you will see this step in the aplay -v output). You might also want to try S32_LE, which would preserve the resolution of 24 bit audio while (hopefully?) avoiding the problem causing the noise.

Regarding the noise problem - Your aplay test says it is not a driver or DAC problem. The problem is within xbmc (which test 1 should confirm). Interestingly, I stumbled across another case where s24_le data produces noise. Playing that sample on Windows with vlc also fails! Now, what does xbmc under Linux on a pi have in common with vlc under windows on a pc? ffmpeg/libav...

and Thank YOU for running the tests!

Hi,

all my test are done with Milhouse build #0922

1. destroyed sound in xbmc

3. with

Code:
pcm.!default {
    type plug
    slave {
        pcm {
        type hw
        card 0
        format S16_LE
        rate "unchanged"
        channels "unchanged"
}   }   }


i get destroyed sound in xbmc and with aplay i get the following output.

Code:
OpenELEC:~ # aplay -vv -D default /storage/music/s24_le.wav
ALSA lib /home/neil/projects/OpenELEC.tv/build.OpenELEC-RPi.arm-devel/alsa-lib-1.0.28/src/pcm/pcm_hw.c:1707:(_snd_pcm_hw_open) Invalid type for rate
aplay: main:722: audio open error: Invalid argument
OpenELEC:~ #

With

Code:
pcm.!default {
    type plug
    slave {
        pcm {
        type hw
        card 0
        format S16_LE
}   }   }

i get destroyed sound in xbmc and with aplay i get the following output but no sound

Code:
OpenELEC:~ # aplay -vv -D default /storage/music/s24_le.wav
Playing WAVE '/storage/music/s24_le.wav' : Signed 24 bit Little Endian, Rate 8000 Hz, Stereo
aplay: set_params:1297: Unable to install hw params:
ACCESS:  RW_INTERLEAVED
FORMAT:  S24_LE
SUBFORMAT:  STD
SAMPLE_BITS: 32
FRAME_BITS: 64
CHANNELS: 2
RATE: 8000
PERIOD_TIME: 125000
PERIOD_SIZE: 1000
PERIOD_BYTES: 8000
PERIODS: 4
BUFFER_TIME: 500000
BUFFER_SIZE: 4000
BUFFER_BYTES: 32000
TICK_TIME: 0
OpenELEC:~ #

With format S32_LE in "asound.conf" the some behavior like above.

PS: I did every time a restart after change the "asound.conf"
PPS: i hope you can read/understand my bad english Angel

Please let me know if i can test another thing for you.

Thank you

EDIT: I just played around with the asound.conf and i see its not necessary to reboot the Pi after i change something. After i renamed the file i was able to play your file again with aplay (no reboot). I think when i restart xbmc with 'systemctl restart xbmc' it use also the new asound.conf. Is that right?
hi,

is anyone else having a problem with the latest builds when using dvdplayer? video is stuttering and with no audio, if I pause playback for a few seconds the stuttering goes away but there is still no sound. All is fine when using omx player. the last build where everything works okay for me is #0918b, 18-Sep-2014

Cheers
Dan
(2014-09-24, 20:20)BoBeRzE Wrote: Hi,

all my test are done with Milhouse build #0922
Quote:
Code:
OpenELEC:~ # aplay -vv -D default /storage/music/s24_le.wav
Playing WAVE '/storage/music/s24_le.wav' : Signed 24 bit Little Endian, Rate 8000 Hz, Stereo
aplay: set_params:1297: Unable to install hw params:
OOPS - those config file incantations can be black magic Smile it should have been
Code:
pcm.!default {
     type plug
     slave {
         rate "unchanged"
         channels "unchanged"
         pcm {
             type hw
             card 0
             format S16_LE
}   }   }
However, the 'afterthought' I posted still applies, you might have to fall back to just
Code:
pcm.!default {
    type hw
    card 0
    format s16_le }
in order for xbmc to play it (and testing s32_le will be interesting)
Quote:EDIT: I just played around with the asound.conf and i see its not necessary to reboot the Pi after i change something. After i renamed the file i was able to play your file again with aplay (no reboot). I think when i restart xbmc with 'systemctl restart xbmc' it use also the new asound.conf. Is what right?
Yes, restarting application should be enough to cause alsa to reread file (in most cases).

and thanks again for your efforts, it is helping to pin things down.
(2014-09-24, 20:20)danny_ice Wrote: is anyone else having a problem with the latest builds when using dvdplayer? video is stuttering and with no audio, if I pause playback for a few seconds the stuttering goes away but there is still no sound. All is fine when using omx player. the last build where everything works okay for me is #0918b, 18-Sep-2014

Can you describe your playback settings?
Can you try changing "sync playback to display" and the 4 "A/V Sync methods"
Hello,

both variants of your asound.conf give me the same. No sound with aplay and a destroyed sound in xbmc.

But i have change the asound.conf as follow. I added device 0
Code:
pcm.!default {
    type hw
    card 0
    device 0
    format s16_le }

now i get

Code:
OpenELEC:~ # aplay -v --device=default /storage/music/s24_le.wav
Playing WAVE '/storage/music/s24_le.wav' : Signed 24 bit Little Endian, Rate 8000 Hz, Stereo
aplay: set_params:1233: Sample format non available
Available formats:
- S16_LE
OpenELEC:~ #

with "format s24_le" in the asound.conf i kann play the file with "aplay" but still nois in xbmc.
(2014-09-24, 21:01)popcornmix Wrote:
(2014-09-24, 20:20)danny_ice Wrote: is anyone else having a problem with the latest builds when using dvdplayer? video is stuttering and with no audio, if I pause playback for a few seconds the stuttering goes away but there is still no sound. All is fine when using omx player. the last build where everything works okay for me is #0918b, 18-Sep-2014

Can you describe your playback settings?
Can you try changing "sync playback to display" and the 4 "A/V Sync methods"

thanks for the quick reply, I have just figured it out, for some reason when I upgraded to the latest nightly it switched the sync method to audio clock. i've changed it back to video clock - resample audio, and it is now working fine

Cheers
Dan
(2014-09-24, 21:11)BoBeRzE Wrote: Hello,

both variants of your asound.conf give me the same. No sound with aplay and a destroyed sound in xbmc.

But i have change the asound.conf as follow. I added device 0
Code:
pcm.!default {
    type hw
    card 0
    device 0
    format s16_le }
duh - In my defense I'll say that isn't always needed Blush

What happens with xbmc with that config (and also with s32_le in that config)?
(2014-09-24, 21:12)danny_ice Wrote: thanks for the quick reply, I have just figured it out, for some reason when I upgraded to the latest nightly it switched the sync method to audio clock. i've changed it back to video clock - resample audio, and it is now working fine

Audio clock is still working okay for me. If you switch back to "audio clock" is it still broken?
I wonder if somehow it wasn't actually on "audio clock", but was just displaying that as it had internally got an invalid setting?
  • 1
  • 94
  • 95
  • 96(current)
  • 97
  • 98
  • 156

Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi Part 3 (Kodi 14.0)8