Now try e.g.:
The verbose debug will show you the actual period_size picked by the driver.
You can even try period_size 1, the player will use the minimum period size allowed by the driver. You may experience xruns in such setup, very tight timing.
Code:
aplay -v -D plughw:1 --period-size=1000 dop.wavThe verbose debug will show you the actual period_size picked by the driver.
You can even try period_size 1, the player will use the minimum period size allowed by the driver. You may experience xruns in such setup, very tight timing.
Sure, flac is just lossless wav compression. The wav and flac "readers" in sox produce identical samples.
aplay -v -D plughw:1 --period-size=256 testfile.wav
Playing with 256 , and got 1 fallout, but yes there are tons of tweaks.
Code:
Playing WAVE 'testfile.wav' : Signed 24 bit Little Endian in 3bytes, Rate 176400 Hz, Stereo
Plug PCM: Linear conversion PCM (S32_LE)
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S24_3LE
subformat : STD
channels : 2
rate : 176400
exact rate : 176400 (176400/1)
msbits : 24
buffer_size : 88200
period_size : 256
period_time : 1451
tstamp_mode : NONE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 256
period_event : 0
start_threshold : 88200
stop_threshold : 88200
silence_threshold: 0
silence_size : 0
boundary : 6206523236469964800
Slave: Hardware PCM card 1 '2Qute' device 0 subdevice 0
Its setup is:
stream : PLAYBACK
access : MMAP_INTERLEAVED
format : S32_LE
subformat : STD
channels : 2
rate : 176400
exact rate : 176400 (176400/1)
msbits : 32
buffer_size : 88200
period_size : 256
period_time : 1451
tstamp_mode : NONE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 256
period_event : 0
start_threshold : 88200
stop_threshold : 88200
silence_threshold: 0
silence_size : 0
boundary : 6206523236469964800
appl_ptr : 0
hw_ptr : 0Playing with 256 , and got 1 fallout, but yes there are tons of tweaks.
Okay this is the result from the listening test.
I did 3 runs on the following period_sizes ( 512 , 2048 , 100000 )
512 - 1 run - 1 skip about 1 sec.
2 run - 2 skips about 1 sec.
3 run - 1 skip about 1 sec.
2048 - 1 run - 1 skip about 1 sec , right in the start of the number.
- 2 run - 1 skip about 1 sec, after ca 60 seconds.
- 3 run - 1 skip about 1 sec , after a long playing time.
100000 - 1 run - 1 skip about 1 sec.
- 2 run - 1 skip about 1 sec , after 4-5 seconds.
- 3 run - 1 skip about 1 sec , after ca 30-35 seconds.
The number is 3.13 min.
PS! period_size : 65536 is the max aplay will take
comment
1) running on the newest kernel 4.12.4 as it's exactly as stable as the old 4.9.39.
2) It's normal the skip comes after 3-5 second(s) in the start of the number.
3) running from SSD Harddrive so No Network related at all.
4) I have 99.77 % idle time on the system.
Done running the test, seems we have a random generator here.
I did 3 runs on the following period_sizes ( 512 , 2048 , 100000 )
512 - 1 run - 1 skip about 1 sec.
2 run - 2 skips about 1 sec.
3 run - 1 skip about 1 sec.
2048 - 1 run - 1 skip about 1 sec , right in the start of the number.
- 2 run - 1 skip about 1 sec, after ca 60 seconds.
- 3 run - 1 skip about 1 sec , after a long playing time.
100000 - 1 run - 1 skip about 1 sec.
- 2 run - 1 skip about 1 sec , after 4-5 seconds.
- 3 run - 1 skip about 1 sec , after ca 30-35 seconds.
The number is 3.13 min.
PS! period_size : 65536 is the max aplay will take
comment
1) running on the newest kernel 4.12.4 as it's exactly as stable as the old 4.9.39.
2) It's normal the skip comes after 3-5 second(s) in the start of the number.
3) running from SSD Harddrive so No Network related at all.
4) I have 99.77 % idle time on the system.
Done running the test, seems we have a random generator here.
Last edited:
Just so we have a reference on DSF files I downloaded this in DSD64 here for free.
http://www.lindberg.no/hires/test/2L50SACD_tr1_DSD_stereo.zip
I made the following 2 testfiles on DOP and another without DOP
When I play the testfile.wav (DOP) through aplay i got these skips all the time, haven't any perfect
the testfile_nodop.wav (No DOP) plays perfect every time with period-size (23,512,2048,65536) no errors.
PS! Period-size can be set between 23-65536..
http://www.lindberg.no/hires/test/2L50SACD_tr1_DSD_stereo.zip
I made the following 2 testfiles on DOP and another without DOP
Code:
sox 2L50SACD_tr1_DSD_stereo.dff -r 176.4k -b 24 testfile.wav dop
sox 2L50SACD_tr1_DSD_stereo.dff -r 176.4k -b 24 testfile_nodop.wavWhen I play the testfile.wav (DOP) through aplay i got these skips all the time, haven't any perfect
the testfile_nodop.wav (No DOP) plays perfect every time with period-size (23,512,2048,65536) no errors.
PS! Period-size can be set between 23-65536..
Last edited:
Did boot the official 4.9.39-1-MANJARO #1 SMP PREEMPT Fri Jul 21 08:25:24 UTC 2017 x86_64 kernel, I did the run on (DOP) , period-size 512,2048,65536
512 - failed
2048 - failed
65536 - failed
And just in case , we would like to try on another PC , I took my old netbook with ubuntu
4.4.0-62-generic #83-Ubuntu SMP Wed Jan 18 14:10:15 UTC 2017 x86_64 x86_64 x86_64 and run the 23,512,2048,65536 and guess what.
It works perfect every time, no single fallout.
I even ran the test three times , just to be sure..
Played the number 12 times in total , works perfect all the times.
I'll just try to repeat the test on another laptop with the same ubuntu server 16.4.x kernel just to see If i'm just as lucky
For the first time we might have something quite useful here...
512 - failed
2048 - failed
65536 - failed
And just in case , we would like to try on another PC , I took my old netbook with ubuntu
4.4.0-62-generic #83-Ubuntu SMP Wed Jan 18 14:10:15 UTC 2017 x86_64 x86_64 x86_64 and run the 23,512,2048,65536 and guess what.
It works perfect every time, no single fallout.
I even ran the test three times , just to be sure..
Played the number 12 times in total , works perfect all the times.
I'll just try to repeat the test on another laptop with the same ubuntu server 16.4.x kernel just to see If i'm just as lucky
For the first time we might have something quite useful here...
Okay testing the exact same kernel 4.4.0-62-generic #83-Ubuntu SMP Wed Jan 18 14:10:15 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux on another more powerful laptop.
Will do the (23,512,2048,65536) test and run it 1 time, starting to get insane listening to the same number.
Okay no errors at all did play the number 4 times in total.
Will do the (23,512,2048,65536) test and run it 1 time, starting to get insane listening to the same number.
Okay no errors at all did play the number 4 times in total.
A little update.
1) got a lot of compiler warnings trying to compile old kernel 4.4.x on my Arch , so I skipped it.
2) The 4.4.x isn't 100% perfect had 2 skips in 50 runs but way way better.
3) Playing with squeezelite now (format: S32_LE,channels: 2,rate: 176400 (176400/1),period_size: 2205,buffer_size: 8820) had 1 skip but I was coping heavyly over network so let it be.
It's for sure a lot to do with the driver as 4.4.x is >20 times more stable (less skips).
Will try MPD later to see If it can be as stable as squeezelite..
1) got a lot of compiler warnings trying to compile old kernel 4.4.x on my Arch , so I skipped it.
2) The 4.4.x isn't 100% perfect had 2 skips in 50 runs but way way better.
3) Playing with squeezelite now (format: S32_LE,channels: 2,rate: 176400 (176400/1),period_size: 2205,buffer_size: 8820) had 1 skip but I was coping heavyly over network so let it be.
It's for sure a lot to do with the driver as 4.4.x is >20 times more stable (less skips).
Will try MPD later to see If it can be as stable as squeezelite..
There are several patches related to usb-audio clock handling between vanilla 4.4 and 4.9.
I think we need to learn more about the character of the dropout.
1) key information - skip or pause?
If paused:
-----------
1) in your php script you can log exact time and momentary frequency parsed from hw_params file (the 50ms interval should be ok)
2) recording with audacity, detecting exact dropout time with ffmpeg -> we can analyze the logged momentary frequency values around the dropout time.
OR
3) with your php skills, it should be possible to write the usb packets parser. We can log exact time for each packet. Also we can record the output and identify exact time of dropout - ffmpeg. Comparing the times, we should be able to identify the packets close to the dropout, perhaps the async feedback gets corrupted and the driver stops/reduces sending samples, I do not know (that would be for the pause case - samples delayed, not skipped).
If skipped
------------
No idea, how a driver could influence random muting the soundcard for a fraction of second.
But first we really need to know the character of the dropout.
Code:
git clone [url]https://github.com/torvalds/linux.git[/url]
cd linux
git whatchanged 12a6116e66695a728bcb9616416c508ce9c051a1..6ff1a25318ebf688ef9593fe09cd449f6fb4ad31 -- sound/usbI think we need to learn more about the character of the dropout.
1) key information - skip or pause?
If paused:
-----------
1) in your php script you can log exact time and momentary frequency parsed from hw_params file (the 50ms interval should be ok)
2) recording with audacity, detecting exact dropout time with ffmpeg -> we can analyze the logged momentary frequency values around the dropout time.
OR
3) with your php skills, it should be possible to write the usb packets parser. We can log exact time for each packet. Also we can record the output and identify exact time of dropout - ffmpeg. Comparing the times, we should be able to identify the packets close to the dropout, perhaps the async feedback gets corrupted and the driver stops/reduces sending samples, I do not know (that would be for the pause case - samples delayed, not skipped).
If skipped
------------
No idea, how a driver could influence random muting the soundcard for a fraction of second.
But first we really need to know the character of the dropout.
Yes I understand... My problem is that I get a tons of error due to different gcc+ compiler restriction when trying to compile older vanilla kernels...
If we could get a vanilla kernel as stable as the ubuntu (patched like crazy) version (4.4.0-62-generic #83), we have some source code (driver etc) which actually works way better that current in use.
The current usb audio driver in linux is more or less a disaster when it comes to Chord 2qute.
It might work great on other soundcard but not Chord 2qute...
Haven't had a single fallout and playing now for almost 2 hours.
If we could get a vanilla kernel as stable as the ubuntu (patched like crazy) version (4.4.0-62-generic #83), we have some source code (driver etc) which actually works way better that current in use.
The current usb audio driver in linux is more or less a disaster when it comes to Chord 2qute.
It might work great on other soundcard but not Chord 2qute...
Haven't had a single fallout and playing now for almost 2 hours.
Hmm, I assume on arch linux it should be simple to compile older 4.x kernels https://wiki.archlinux.org/index.php/Kernels/Traditional_compilation The most tedious stage "make config" can be greatly simplified with "make oldconfig" using a working .config file from /boot/configXXX
IMO the disaster is the Chord 2qute firmware. I believe in DoP it does not follow the USB audio 2 specs and the updated alsa driver somehow collides with some of its deficiencies.
We can call it pure coincidence. This way it will not be fixed for others plus you cannot upgrade kernel to latest versions. Personally I would not be happy with such outcome but since I do not have that hardware (and I do not intend to buy such buggy device), I myself cannot do anything about it
Hmm, I assume on arch linux it should be simple to compile older 4.x kernels https://wiki.archlinux.org/index.php/Kernels/Traditional_compilation The most tedious stage "make config" can be greatly simplified with "make oldconfig" using a working .config file from /boot/configXXX
IMO the disaster is the Chord 2qute firmware. I believe in DoP it does not follow the USB audio 2 specs and the updated alsa driver somehow collides with some of its deficiencies.
We can call it pure coincidence. This way it will not be fixed for others plus you cannot upgrade kernel to latest versions. Personally I would not be happy with such outcome but since I do not have that hardware (and I do not intend to buy such buggy device), I myself cannot do anything about it
As long as you have the interest we'll try to find out how too also help others.
The 4.4.31-1-MANJARO #1 SMP PREEMPT Thu Nov 10 20:44:32 UTC 2016 I'm testing right now seems too be very stable.
I'm compiling a vanilla kernel based on 4.4.31-1 , when/if we have a relative stable vanilla kernel we have at least something us linux people can use.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.