STR: 1. Visit http://clb.confined.space/audio_test_suite/ (or git clone the site down for local examination from https://github.com/juj/audio_test_suite ) 2. Open page 'shanghai_action' 3. Click the button 'shanghai_action_44100hz_1411kbs_stereo_int16.wav'. Expected: The page should play back a seamlessly looping audio file as a MediaElementAudioSource with loop: true. Observed: When the audio clip loops, there is a short pause/seam each time in the audio.
How long is this audio? I listened for it for a while, but not knowing when to expect it to loop, and getting distracted, I wasn't sure if I could reproduce.
<rdar://problem/83358494>
Actually now I realize there is a better test case for the bug in my suite. Better STR: 1. Visit http://clb.confined.space/audio_test_suite/car_acceleration_high/car_acceleration_high.html 2. Click the first compressed playback button: "car_acceleration_high_44100hz_706kbs_mono_int16.wav" that showcases the distinct pause between loops. Made a video to showcase the issue: http://clb.confined.space/bugs/Safari_looping_compressed_audio_bug.mkv The gap between the loops was tested to occur on the following setups: MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports) - macOS Catalina 10.15.6 (19G2021) - STP Release 122 (Safari 14.2, WebKit 15612.1.6.2) MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports) (same from above) - macOS Catalina 10.15.6 (19G2021) - Safari 14.0 (15610.1.28.1.9, 15610) Mac mini (2018) - macOS Big Sur 11.6 (20G165) - Safari 14.1.2 (16611.3.10.1.6) Mac mini (2018) (same from above) - macOS Big Sur 11.6 (20G165) - STP Release 132 (Safari 15.4, WebKit 16613.1.1.5)
(In reply to jujjyl from comment #3) > Actually now I realize there is a better test case for the bug in my suite. > > Better STR: > > 1. Visit > http://clb.confined.space/audio_test_suite/car_acceleration_high/ > car_acceleration_high.html > 2. Click the first compressed playback button: > "car_acceleration_high_44100hz_706kbs_mono_int16.wav" > > that showcases the distinct pause between loops. > > Made a video to showcase the issue: > > http://clb.confined.space/bugs/Safari_looping_compressed_audio_bug.mkv > > The gap between the loops was tested to occur on the following setups: > > MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports) > - macOS Catalina 10.15.6 (19G2021) > - STP Release 122 (Safari 14.2, WebKit 15612.1.6.2) > > MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports) (same from above) > - macOS Catalina 10.15.6 (19G2021) > - Safari 14.0 (15610.1.28.1.9, 15610) > > > Mac mini (2018) > - macOS Big Sur 11.6 (20G165) > - Safari 14.1.2 (16611.3.10.1.6) > > Mac mini (2018) (same from above) > - macOS Big Sur 11.6 (20G165) > - STP Release 132 (Safari 15.4, WebKit 16613.1.1.5) I clicked on the first button. It played through once (without hiccup) but it didn't loop. I tried the same thing in Chrome and the behavior was exactly the same.
That is odd. Note that the URL you post in your comment incorrectly reads http://clb.confined.space/audio_test_suite/car_acceleration_high/ the bugs.webkit.org webpage cuts it off in your reply message. It should instead be http://clb.confined.space/audio_test_suite/car_acceleration_high/car_acceleration_high.html see the Comment 3 reply. That is, visit the .html web page, and not the web server autoindex page. If I visit the web server autoindex page and directly play back a .wav file from there, it also plays just once. Maybe you had visited that instead?
(In reply to jujjyl from comment #5) > That is odd. Note that the URL you post in your comment incorrectly reads > > http://clb.confined.space/audio_test_suite/car_acceleration_high/ > > the bugs.webkit.org webpage cuts it off in your reply message. It should > instead be > > http://clb.confined.space/audio_test_suite/car_acceleration_high/ > car_acceleration_high.html > > see the Comment 3 reply. > > That is, visit the .html web page, and not the web server autoindex page. > > If I visit the web server autoindex page and directly play back a .wav file > from there, it also plays just once. Maybe you had visited that instead? I definitely went to http://clb.confined.space/audio_test_suite/car_acceleration_high/car_acceleration_high.html and clicked the first button. The audio played fine for ~25 seconds until the end of the acceleration and then stopped (no looping). Same behavior is observed in Chrome 93. I am on macOS 12 (Monterey) beta which should be similar to Safari Technology Preview.
Oh, you must have played the uncompressed version since you got an audio that lasted 25 seconds. The STR asks to play the first button in the compressed section. See the video for a walkthrough.
(In reply to jujjyl from comment #7) > Oh, you must have played the uncompressed version since you got an audio > that lasted 25 seconds. The STR asks to play the first button in the > compressed section. > > See the video for a walkthrough. Ah indeed, I had to click the first button in the second (compressed) section to reproduce. I definitely hear a pause between the loops now. The behavior is different than in Chrome. I'll investigate as soon as I have some spare cycles. Note that I wasn't able to play the video with whatever software I have on my macOS. I guess I'd need to install something to play a mkv.
(In reply to Chris Dumez from comment #8) > (In reply to jujjyl from comment #7) > > Oh, you must have played the uncompressed version since you got an audio > > that lasted 25 seconds. The STR asks to play the first button in the > > compressed section. > > > > See the video for a walkthrough. > > Ah indeed, I had to click the first button in the second (compressed) > section to reproduce. I definitely hear a pause between the loops now. The > behavior is different than in Chrome. I'll investigate as soon as I have > some spare cycles. cc'ing a few media people as there is very little WebAudio used in the compressed case. It is using a looping <audio> element as source in the audio graph via a MediaElementAudioSource. The looping logic happens on media side and not on WebAudio side. I am curious if we could reproduce the issue without involving WebAudio at all, just via an <audio> element.
*** Bug 134929 has been marked as a duplicate of this bug. ***
*** Bug 28748 has been marked as a duplicate of this bug. ***
(In reply to Chris Dumez from comment #9) > I am curious if we could reproduce the issue without involving WebAudio at > all, just via an <audio> element. The old issues which I've dupe'd here (as this is in Radar and discussion has happened here) imply this also happens with an audio element.