diff --git a/README_v2024.md b/README_v2024.md
index 76bbefaba637c6f9614bf7aa91e3b7f599ea1620..d5c3596a77e48ab08cd6e3d0c77a01462c1915e1 100644
--- a/README_v2024.md
+++ b/README_v2024.md
@@ -133,43 +133,50 @@ Like for the previous evaluation , it's not possible to reconfigure a running
 device. That means, to reconfigure the sample rate input, we have to force the
 device input to be idle.
 
+The script for this test was adjusted for the new pipewire behavior. In the
+previous evaluation, pipewire assigned each JACK client to a unique node group
+based on their PID (i.e. "jack-PID"). With recent versions of pipewire, all JACK
+clients are assigned to the same node group called "group.dsp.0" (see commit
+[bafa890a](https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/bafa890aefbadb0535047fa1b4ab3846acc7cef1)).
+The aim of this change was to schedule all JACK clients together, but this change
+affects our test since we want to reconfigure only one node without touching
+the other ones. However, it is possible to force our different JACK clients to
+be in different groups allowing us to restore the previous pipewire behavior and
+to reconfigure only specific JACK nodes. The node group is defined within the
+PIPEWIRE_PROPS variable when the client is started:
+```
+# Start a first instance of sndfile-jackplay which is assigned to the "group_A" node group
+PIPEWIRE_PROPS='{ node.group = group_A }' pw-jack sndfile-jackplay test300.wav
+# Start a second instance of sndfile-jackplay which is assigned to the "group_B" node group
+PIPEWIRE_PROPS='{ node.group = group_B }' pw-jack sndfile-jackplay test300.wav
+```
+
 During the test, two wav files are generated `test-case-capture1.wav` and
 `test-case-capture2.wav` (both are available in `results_v2024/test-case-2/`).
 The first one captures the sound coming from the board built-in sound card while
 the second capture the sound coming from the board USB sound card.
 
+In `test-case-capture1.wav`, we can hear the `test300.wav` tone without any
+artefact and without any interruption. This stream is therefore not affected by
+the reconfiguration of the input of the other sound card.
+
 In the file `test-case-capture2.wav`, the stream starts with the `test300.wav`
-tone, then at *0:09* we start hearing the `test800.wav` tone which is captured
+tone, then at *0:10* we start hearing the `test800.wav` tone which is captured
 at 44100 Hz and mixed to the first tone. We stop hearing the `test800.wav` tone
-at *0:19* while the `test300.wav` tone is still audible. This pause of the
+at *0:20* while the `test300.wav` tone is still audible. This pause of the
 `test800.wav` tone continues for 5 secs allowing the reconfigure the capture
-input rate at 48000 Hz by waiting the input device to be idle. Then, at *0:24*
+input rate at 48000 Hz by waiting the input device to be idle. Then, at *0:25*
 we hear again a mix of `test300.wav` and `test800.wav` captured at 48000 Hz
-for 10 secs. At *0:34*, we stop hearing the `test800.wav` tone because of the
+for 10 secs. At *0:35*, we stop hearing the `test800.wav` tone because of the
 reconfiguration at 44100 Hz, which restart 5 secs later and so.
 The sample rate reconfiguration is checked during the test in the `FORMAT` column
 of the `pw-top` output.
 
-Interestingly, in `test-case-capture1.wav` we can hear a brief crack when a capture
-starts and stops, i.e. at *0:09*, *0:19*, *0:24*, *0:34* and so on. This looks to
-be a regression compared to the previous evaluation where the unrelated output
-was not affected by the capture. The pipewire graph `pw-dot-temp-mic-0.png`
-don't show any links between the input and the unrelated output, but interestingly
-the output of `pw-top` shows that **all** runnings nodes during the test are driven
-by the same driver node `alsa_input.usb-0d8c_USB_Sound_Device-00.analog-stereo`
-whereas it would make sense to use two different groups with different driver
-nodes here. Recent changes
-([1](https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/bafa890aefbadb0535047fa1b4ab3846acc7cef1) and
-[2](https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3612#note_2146503))
-in pipewire suggest that is not a bug but rather a feature that we could configure.
-
-To compare to the previous evaluation, the direct stream is affected in the same
-way, i.e. the reconfiguration of audio capture only impacts the captured stream
-and not the direct output since we have to stop the stream to make pipewire
-apply the changes. But in this new version, the unrelated output is affected by
-a small crack whereas it was not affected previously with a note of caution as
-some recent changes in pipewire seem to indicate that this is due to an expected
-and customizable behavior.
+There is no change compared to the previous evaluation. The reconfiguration of
+audio capture only impacts the captured stream and not the direct output since
+we have to stop the stream to make pipewire apply the changes. Morevoer, the
+unrelated output is not affected.
+
 
 # Test case 3: Capturing multiple inputs to multiple outputs
 
@@ -350,9 +357,11 @@ artefacts.
 # Results summary (comparing results to the previous evaluation)
 - Test case 1: Compared to the previous evaluation, there is no change in the
   results: streams are smoooth and no artefacts are audible when the switch happens.
-- Test case 2: In contrast to the previous evaluation, the unrelated output is
-  affected by the start and stop of the capture, but this seems customizable by
-  forcing our different nodes into different groups driven by different driver nodes.
+- Test case 2: After adjusting the test script to the new pipewire behavior,
+  results are similar to the previous evaluation: only the reconfigured stream
+  is affected as we have to make the input device idle to force pipewire to
+  apply the changes. The direct or unrelated outputs are not affected themselves
+  by the reconfiguration.
 - Test case 3: In this test, results are improved as we don't hear sound artefacts
   due to mixing streams like in the previous evaluation. Streams are smooth without
   hatching sound or loud cracking noise. We can hear few light cracking, but this probably
diff --git a/results_v2024/test-case-2/pw-dot-temp-mic-0.png b/results_v2024/test-case-2/pw-dot-temp-mic-0.png
deleted file mode 100644
index a20f77294881594473aedbd67a0ffaddfe44f220..0000000000000000000000000000000000000000
Binary files a/results_v2024/test-case-2/pw-dot-temp-mic-0.png and /dev/null differ
diff --git a/results_v2024/test-case-2/pw-dot-temp-my-sink-B-4.png b/results_v2024/test-case-2/pw-dot-temp-my-sink-B-4.png
deleted file mode 100644
index e106aa8474ba13fd1373ae94786b287b02326e44..0000000000000000000000000000000000000000
Binary files a/results_v2024/test-case-2/pw-dot-temp-my-sink-B-4.png and /dev/null differ
diff --git a/results_v2024/test-case-2/test-case-capture1.wav b/results_v2024/test-case-2/test-case-capture1.wav
index 0f1c6f9945733957e8fced7570e4b612d3de574b..1ee94eeb638f5560706731db752489834b1df556 100644
Binary files a/results_v2024/test-case-2/test-case-capture1.wav and b/results_v2024/test-case-2/test-case-capture1.wav differ
diff --git a/results_v2024/test-case-2/test-case-capture2.wav b/results_v2024/test-case-2/test-case-capture2.wav
index 1160e4a8552487766b5ab52ff470da8316951811..51b91dcf723fd0e32f60ab2f7d32cb626bcfaff1 100644
Binary files a/results_v2024/test-case-2/test-case-capture2.wav and b/results_v2024/test-case-2/test-case-capture2.wav differ