Just compare the period_size for sox, squeezelite, mpd, aplay reported in this thread (from outputs or hw_params). The larger, the more dropouts. That is an important observation.
Just for fun i converted the wav (DOP ready) back to Flac and played it in sox.
Now I just play the FLAC file and Chord is in DOP , white light.
The size is a few percent larger than the orig DSF file...
Now I just play the FLAC file and Chord is in DOP , white light.
The size is a few percent larger than the orig DSF file...
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.
Please try playing with the period_size param (e.g. 512, or something huge 100000 to force the maximum limit) and check if it has an effect on the fallouts.
Sorry, going to bed now. We have moved a lot forward today, thanks.
Sorry, going to bed now. We have moved a lot forward today, thanks.
Yes we have tried a lot and I'm appreciate your help a lot. I learn a lot about all aspect
of my problematic DAC.
Tomorrow I'll do some statistic and try different period_sizes...
Will take 3 runs on for instance 512 , 2048 100000 ... Will find another number this I'm playing sucks..
of my problematic DAC.
Tomorrow I'll do some statistic and try different period_sizes...
Will take 3 runs on for instance 512 , 2048 100000 ... Will find another number this I'm playing sucks..
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:
Great. The errors are not correlated to period size. Please can you check correlation to buffer size too? Very unlikely, but still...
That is --buffer-size param of aplay.
Did we conclude the glitches are skips or pauses?
That is --buffer-size param of aplay.
Did we conclude the glitches are skips or pauses?
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.
Will download the exact same kernel too the Arch laptop (which has these DOP problems) and see If
I can compile the same kernel and get rid of the problems.
I can compile the same kernel and get rid of the problems.
Well, if you can find two vanilla kernels (no backported patches in sound subsystem) - working and problematic, we are half way to success.
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.
Too see If we can use another 2016 distro I'll try the manjaro-xfce-16.06-x86_64.iso , on one of my
laptops. The ubuntu 16.4.2 is my ref so far. Won't change any settings on the ref, unless I can make another at least as stable.
laptops. The ubuntu 16.4.2 is my ref so far. Won't change any settings on the ref, unless I can make another at least as stable.
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
- Not open for further replies.